[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160331201012.GR9862@port70.net>
Date: Thu, 31 Mar 2016 22:10:14 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: size_t and int64_t on a new platform
* Rich Felker <dalias@...c.org> [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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
