From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9801 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: size_t and int64_t on a new platform Date: Thu, 31 Mar 2016 22:10:14 +0200 Message-ID: <20160331201012.GR9862@port70.net> References: <20160331192518.GW21636@brightrain.aerifal.cx> 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 1459455046 1081 80.91.229.3 (31 Mar 2016 20:10:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 31 Mar 2016 20:10:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9814-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 31 22:10:30 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 1alivF-0006Kg-1s for gllmg-musl@m.gmane.org; Thu, 31 Mar 2016 22:10:29 +0200 Original-Received: (qmail 22096 invoked by uid 550); 31 Mar 2016 20:10:27 -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 22078 invoked from network); 31 Mar 2016 20:10:26 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20160331192518.GW21636@brightrain.aerifal.cx> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9801 Archived-At: * Rich Felker [2016-03-31 15:25:18 -0400]: > 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? > there are currently two targets in gcc that do the same (openbsd and vms), so most likely the alternative typedefs are not an issue. (i don't think powerpc64 is different, the same glibc-stdint.h is used for all *-linux* targets in gcc) however musl has to match the abi the compiler assumes (a compiler does not need to know about the typedefs normally, but printf fmt warnings and fortran c ffi rely on the compiler's knowledge about these typedefs) so the compiler has to be configured accordingly.