[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACcSVPFAj=-BEvmLhQsqsJuT6sKLGySh1uESAhctah3UpCv1BQ@mail.gmail.com>
Date: Thu, 31 Mar 2016 11:20:22 -0700
From: Dan Gohman <sunfish@...illa.com>
To: musl@...ts.openwall.com
Subject: size_t and int64_t on a new platform
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?
Thanks,
Dan
Content of type "text/html" skipped
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.
