From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9195 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Bits deduplication: current situation Date: Mon, 25 Jan 2016 22:32:55 +0100 Message-ID: <20160125213255.GK9621@port70.net> References: <20160125035925.GA2288@brightrain.aerifal.cx> <20160125210005.GC238@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1453757592 3677 80.91.229.3 (25 Jan 2016 21:33:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2016 21:33:12 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9208-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 25 22:33:09 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aNol3-0002A6-N0 for gllmg-musl@m.gmane.org; Mon, 25 Jan 2016 22:33:09 +0100 Original-Received: (qmail 11895 invoked by uid 550); 25 Jan 2016 21:33:07 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 11873 invoked from network); 25 Jan 2016 21:33:07 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20160125210005.GC238@brightrain.aerifal.cx> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9195 Archived-At: * 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? > 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.)