Date: Mon, 25 Jan 2016 21:03:54 -0800 From: Dan Gohman <sunfish@...illa.com> To: musl@...ts.openwall.com Subject: Re: Bits deduplication: current situation On Mon, Jan 25, 2016 at 1:32 PM, Szabolcs Nagy <nsz@...t70.net> wrote: > * Rich Felker <dalias@...c.org> [2016-01-25 16:00:05 -0500]: > > On Mon, Jan 25, 2016 at 11:22:13AM -0800, Dan Gohman wrote: > > > Concerning stdint.h, there are a few details beyond just 32-bit vs > 64-bit. > > > For example, int64_t can be either "long" or "long long" on an LP64 > target. > > > The difference usually doesn't matter, but there are things which end > up > > > noticing, like C++ name mangling and C format-string checking. > > > > I'm pretty sure int64_t is long on all LP64 targets we support. Are > > there others that differ? > I'm working on an architecture which does, though there's no musl support for it currently. note that the patch is wrong for all released versions of gcc (<=5) > because the *fast types are different on musl vs glibc on 64bit arches. > (fwiw newlib defines these types in yet another way) > > this is not visible in the libc abi but matters for third-party > code compiled against musl headers and those should be abi > compat no matter what compiler you used. > > (with gcc the difference matters if you use the gcc provided stdatomic.h > or use the gfortran c ffi, but then you probably built a gcc > with musl support anyway and then the types are consistent.) > Ah, I was unaware that musl and glibc differ here. I agree that that complicates the patch I had envisioned, so I'll drop the idea for now. 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.