From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9203 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Bits deduplication: current situation Date: Tue, 26 Jan 2016 15:17:04 -0500 Message-ID: <20160126201703.GG238@brightrain.aerifal.cx> References: <20160125035925.GA2288@brightrain.aerifal.cx> <20160125210005.GC238@brightrain.aerifal.cx> <20160125213255.GK9621@port70.net> 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 1453839442 13577 80.91.229.3 (26 Jan 2016 20:17:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Jan 2016 20:17:22 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9216-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 26 21:17:21 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 1aOA3F-0006Ot-Ks for gllmg-musl@m.gmane.org; Tue, 26 Jan 2016 21:17:21 +0100 Original-Received: (qmail 17445 invoked by uid 550); 26 Jan 2016 20:17:19 -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 17426 invoked from network); 26 Jan 2016 20:17:18 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9203 Archived-At: On Mon, Jan 25, 2016 at 09:03:54PM -0800, Dan Gohman wrote: > 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. Is this for Linux to run on, or for non-Linux use? I'm pretty sure GCC wants the above policy for LP64 to be followed on all Linux targets, and generally considers this part of the general ABI descended from sysv. Doing it differently is surely a gratuitous incompatibility and pain for implementations. Rich