[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160125213255.GK9621@port70.net>
Date: Mon, 25 Jan 2016 22:32:55 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Bits deduplication: current situation
* 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?
>
the convention is to use the smallest rank integer type with the
right range.
there may be other issues, but in general a c compiler does not
need to know these typedefs.
> > GCC >= 4.5 and clang predefine macros providing almost everything stdint.h
> > (and inttypes.h) needs. For example, see the attached file. Would you be
> > interested in a patch which refactors stdint.h to use this approach by
> > default, with a mechanism to support older compilers if needed?
>
> No, the intent is that the public headers be compatible with basically
> all compilers honoring the ABI, not just gcc and compatible ones.
> There are a very small number of things (documented in the outdated
> manual) that need extensions in the public headers, mainly _Complex_I,
> tgmath.h, and stdarg.h, and in those cases we use the conventions that
> gcc and other existing compilers have created.
>
> Also it's musl's intent to be explicit with definitions, and this is
> actually helpful with the C++ types issue. IMO it's much better to get
> an error that a new compiler you're trying has the ABI wrong than to
> silently use different types.
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.)
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.
