From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9206 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Bits deduplication: current situation Date: Tue, 26 Jan 2016 21:26:00 +0100 Message-ID: <20160126202559.GM9621@port70.net> References: <20160125035925.GA2288@brightrain.aerifal.cx> <20160125210005.GC238@brightrain.aerifal.cx> <20160125213255.GK9621@port70.net> <20160126101844.GL9621@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 1453840024 23750 80.91.229.3 (26 Jan 2016 20:27:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 26 Jan 2016 20:27:04 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9218-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 26 21:27:03 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 1aOABq-0005XN-Gv for gllmg-musl@m.gmane.org; Tue, 26 Jan 2016 21:26:14 +0100 Original-Received: (qmail 22364 invoked by uid 550); 26 Jan 2016 20:26:12 -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 22335 invoked from network); 26 Jan 2016 20:26:12 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9206 Archived-At: * Dan Gohman [2016-01-26 07:16:08 -0800]: > On Tue, Jan 26, 2016 at 2:18 AM, Szabolcs Nagy wrote: > > * Dan Gohman [2016-01-25 21:03:54 -0800]: > > > On Mon, Jan 25, 2016 at 1:32 PM, Szabolcs Nagy wrote: > > > > * Rich Felker [2016-01-25 16:00:05 -0500]: > > > > > > > > > > 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. > > > > > > > in gcc stdint.h only depends on libc/os and sizeof(long), > > not on architecture. > > > > (e.g. openbsd uses long long, glibc uses long consistently > > for all LP64 arch abis.) > > > > I've been assuming that, in the absence of compatibility constraints (for > example on a new architecture), it would be reasonable for hypothetical new > musl, glibc, or newlib ports to arrange to be ABI compatible at the level > of a freestanding implementation (in the C standard sense), which would > include . Is this an incorrect assumption, from your perspective? it is correct in principle, but it means a bit more toolchain work to support an inconsistent arch and it can bite you if you work with historical code with invalid assumptions. gcc/musl/glibc/linux all use consistent typedefs for all 64bit archs, most likely other projects do the same. in most cases it should be easy to do the typedefs differently for a new arch, but there might be caveats.. i think if you want to design a freestanding c language abi for your arch then it makes sense to follow what's already there (unless you have some specific reason to deviate).