From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9800 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: size_t and int64_t on a new platform Date: Thu, 31 Mar 2016 15:25:18 -0400 Message-ID: <20160331192518.GW21636@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1459452335 22825 80.91.229.3 (31 Mar 2016 19:25:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Mar 2016 19:25:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9813-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 31 21:25:34 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aliDl-0003za-TK for gllmg-musl@m.gmane.org; Thu, 31 Mar 2016 21:25:33 +0200 Original-Received: (qmail 30060 invoked by uid 550); 31 Mar 2016 19:25:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 30042 invoked from network); 31 Mar 2016 19:25:31 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9800 Archived-At: On Thu, Mar 31, 2016 at 11:20:22AM -0700, Dan Gohman wrote: > I'm working on a new architecture (WebAssembly, aka wasm) and am hoping to > have a compatible ABI at the level of a "freestanding implementation" > between all libc ports. > > The current design would translate into the following in a musl port (in > ..../bits/alltypes.h.in): > > #define _Addr long > #define _Int64 long long > > Both the ILP32 and LP64 platform variants would use the same definitions. > This helps minimize differences between the two variants, which aligns with > an overall goal of the platform. > > However, this differs from musl's convention of using "int" for _Addr on > ILP32 systems and using "long" for _Int64 on LP64 systems. But, as far as I > can tell, no musl code actually depends on this convention. Almost all code > in musl is either fully portable and can't, or is architecture-specific and > can just do the right thing for its own architecture. > > Legacy code may have assumptions, though I'm aware of the issues and don't > believe it's a significant practical problem for WebAssembly. > > If we decide to contribute wasm support upstream to the musl project in the > future, would the musl maintainers expect to be ok with the above > definitions? At some point we'll probably have to make this relaxation anyway. I've heard there's at least one arch we're planning to add (maybe powerpc64? I forget) that's using long instead of int for _Addr types. What would be most helpful to us (to keep things simple) is just ensuring that all the relevant types (size_t, ssize_t, ptrdiff_t, [u]intptr_t, etc.) are defined consistently as int or as long; otherwise we have to pop a hole in the abstraction they're modeled with now. That wouldn't be a huge problem either but it just adds more redundancy to arch/*/bits/alltypes.h.in files. Anyone else have objections to use of long for these types? Rich