From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9135 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: the size of the int type Date: Fri, 15 Jan 2016 16:33:14 -0500 Message-ID: <20160115213313.GH238@brightrain.aerifal.cx> References: 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 1452893612 27921 80.91.229.3 (15 Jan 2016 21:33:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jan 2016 21:33:32 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9148-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 15 22:33:32 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 1aKBzt-0008Lr-3G for gllmg-musl@m.gmane.org; Fri, 15 Jan 2016 22:33:29 +0100 Original-Received: (qmail 15988 invoked by uid 550); 15 Jan 2016 21:33:26 -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 15967 invoked from network); 15 Jan 2016 21:33:26 -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:9135 Archived-At: On Fri, Jan 15, 2016 at 04:01:12PM -0500, Max Ruttenberg wrote: > Hi, > > I'm wondering if there's any code in musl that makes assumptions on the > size of the "int" type. > > I only ask because I'm debating how my compiler (which targets a machine > with a 64-bit word size) should define the int type. Ideally I'd like to > break as little library code as possible. The musl headers "assume" int is 32-bit in the sense that 32-bit types are defined in the top-level headers with 'int' or 'unsigned' rather than being arch-specific/bits-headers-level. This is not a so much a code-level assumption as a simplification of the headers, but it's not one where I'd want to introduce extra gratuitous abstraction upstream. If int is not 32-bit, then you can't define both 16-bit and 32-bit types ([u]int{16,32}_t) without needing a nonstandard (extended) integer type for at least one of them since short is the only standard type that's smaller. In addition, futex-related code sort of assumes int is 32-bit. There's code that treats 'bit 31 set' and 'negative' as equivalent conditions, code that uses hard-coded bits of the futex word (both for private purposes and to match kernel ABI for robust mutexes, etc.), and perhaps other issues. This code would need additional abstraction to support other-than-32-bit int. Finally, making int larger than 64-bit would break a lot of application code. While modern applications are written with the understanding that default promotions cause arithmetic on [u]int8_t and [u]int16_t to actually happen as signed arithmetic in type int, everybody (wrongly, from a portability standpoint) assumes uint32_t arithmetic is actually unsigned arithmetic and wraps as expected. If int were higher-rank than uint32_t, such arithmetic would happen as signed int, and overflows would be undefined behavior, not wrapping. Lots of other nasty issues with default promotions arise too. So in summary, I think making int 64-bit is a bad idea, and not something I'd want to make the effort to support upstream in musl. LP64 is the "right" model for 64-bit ABIs. Rich