[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Jan 2016 16:33:14 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: the size of the int type
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
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.
