Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 25 Jan 2016 21:03:54 -0800
From: Dan Gohman <>
Subject: Re: Bits deduplication: current situation

On Mon, Jan 25, 2016 at 1:32 PM, Szabolcs Nagy <> wrote:

> * Rich Felker <> [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.



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.