[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACcSVPG_hmeAJnbuQPe1HatKS4tiezqugabXhWfUk-g7One=Ow@mail.gmail.com>
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.
