the size of the int type

the size of the int type

[Max Ruttenberg]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

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.

Max

[-- Attachment #2: Type: text/html, Size: 417 bytes --]

Re: the size of the int type

[Josiah Worcester]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

I do not know of anything in musl that assumes "int" is 32-bit, but I'm
confident that implementing it as anything else will break a large amount
of third party code. Practically all platforms in common use have 32-bit
int (regardless of the machine's word size), and as such a lot of code
relies on this (implicitly or explicitly).
You would do better to match the convention used on modern-day Unix
systems, where int is 32-bit, long is the machine word size, and long long
is 64-bit. If you do this everything should pretty much function as it
expects, with regard to the standard C types' sizes.

On Fri, Jan 15, 2016 at 1:01 PM Max Ruttenberg <
mruttenberg@emutechnology.com> 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.
>
> Max
>

[-- Attachment #2: Type: text/html, Size: 1400 bytes --]

Re: the size of the int type

[Max Ruttenberg]

[-- Attachment #1: Type: text/plain, Size: 1249 bytes --]

Thank you!

On Fri, Jan 15, 2016 at 4:11 PM, Josiah Worcester <josiahw@gmail.com> wrote:

> I do not know of anything in musl that assumes "int" is 32-bit, but I'm
> confident that implementing it as anything else will break a large amount
> of third party code. Practically all platforms in common use have 32-bit
> int (regardless of the machine's word size), and as such a lot of code
> relies on this (implicitly or explicitly).
> You would do better to match the convention used on modern-day Unix
> systems, where int is 32-bit, long is the machine word size, and long long
> is 64-bit. If you do this everything should pretty much function as it
> expects, with regard to the standard C types' sizes.
>
> On Fri, Jan 15, 2016 at 1:01 PM Max Ruttenberg <
> mruttenberg@emutechnology.com> 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.
>>
>> Max
>>
>


-- 
Max Ruttenberg,
Member of the Technical Staff
Emu *Technology*
1400 E Angela Blvd, Unit 101
South Bend, IN 46617

[-- Attachment #2: Type: text/html, Size: 2539 bytes --]

Re: the size of the int type

[Rich Felker]

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

Re: the size of the int type

[croco]

On Fri, Jan 15, 2016 at 09:11:25PM +0000, Josiah Worcester wrote:

> You would do better to match the convention used on modern-day Unix
> systems, where int is 32-bit, long is the machine word size, and long long
> is 64-bit. If you do this everything should pretty much function as it
> expects, with regard to the standard C types' sizes.

Let me second this.  Please note that in case you implement int as 64-bit,
then there will be either no 32-bit or no 16-bit integer type (at all), as
there's only the short which is in between char ant int; hence, well, there
will be a kind of problem with some typedefs from <stdint.h>: either
int16_t/uint16_t or int32_t/uint32_t will actually have a size different
from what the name suggests, so you'll run into a trouble with
reading/analysing data in binary formats.



--
Croco

Re: the size of the int type

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1803 bytes --]

Am Samstag, den 16.01.2016, 14:09 +0300 schrieb croco@openwall.com:
> On Fri, Jan 15, 2016 at 09:11:25PM +0000, Josiah Worcester wrote:
> 
> > You would do better to match the convention used on modern-day Unix
> > systems, where int is 32-bit, long is the machine word size, and long long
> > is 64-bit. If you do this everything should pretty much function as it
> > expects, with regard to the standard C types' sizes.
> 
> Let me second this.  Please note that in case you implement int as 64-bit,
> then there will be either no 32-bit or no 16-bit integer type (at all), as
> there's only the short which is in between char ant int; hence, well, there
> will be a kind of problem with some typedefs from <stdint.h>: either
> int16_t/uint16_t or int32_t/uint32_t will actually have a size different
> from what the name suggests, so you'll run into a trouble with
> reading/analysing data in binary formats.

You certainly shouldn't do it like that. If you can't support
[u]intXX_t for some XX, you shouldn't define these types. These are
optional types in the C standard, but if they are defined they must
have the exact width, and the intXX_t must have two's complement
representation.

Mandatory are only the [u]int_leastXX_t types for XX = 8, 16, 32 and
64. But as the name indicates, these don't have to have the exact
width.

In any case you should just stick to the standard ABI of your
platform. Everything else would be opening a can of worms.

Jens


-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::




[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: the size of the int type

[Max Ruttenberg]

[-- Attachment #1: Type: text/plain, Size: 2177 bytes --]

All,

Thank you! You have convinced me that I should leave int as 32-bit, long
long as 64-bit, and long as the word size of the machine.

On Sat, Jan 16, 2016 at 8:09 AM, Jens Gustedt <jens.gustedt@inria.fr> wrote:

> Am Samstag, den 16.01.2016, 14:09 +0300 schrieb croco@openwall.com:
> > On Fri, Jan 15, 2016 at 09:11:25PM +0000, Josiah Worcester wrote:
> >
> > > You would do better to match the convention used on modern-day Unix
> > > systems, where int is 32-bit, long is the machine word size, and long
> long
> > > is 64-bit. If you do this everything should pretty much function as it
> > > expects, with regard to the standard C types' sizes.
> >
> > Let me second this.  Please note that in case you implement int as
> 64-bit,
> > then there will be either no 32-bit or no 16-bit integer type (at all),
> as
> > there's only the short which is in between char ant int; hence, well,
> there
> > will be a kind of problem with some typedefs from <stdint.h>: either
> > int16_t/uint16_t or int32_t/uint32_t will actually have a size different
> > from what the name suggests, so you'll run into a trouble with
> > reading/analysing data in binary formats.
>
> You certainly shouldn't do it like that. If you can't support
> [u]intXX_t for some XX, you shouldn't define these types. These are
> optional types in the C standard, but if they are defined they must
> have the exact width, and the intXX_t must have two's complement
> representation.
>
> Mandatory are only the [u]int_leastXX_t types for XX = 8, 16, 32 and
> 64. But as the name indicates, these don't have to have the exact
> width.
>
> In any case you should just stick to the standard ABI of your
> platform. Everything else would be opening a can of worms.
>
> Jens
>
>
> --
> :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
> :: ::::::::::::::: office Strasbourg : +33 368854536   ::
> :: :::::::::::::::::::::: gsm France : +33 651400183   ::
> :: ::::::::::::::: gsm international : +49 15737185122 ::
> :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
>
>
>
>


-- 
Max Ruttenberg,
Member of the Technical Staff
Emu *Technology*
1400 E Angela Blvd, Unit 101
South Bend, IN 46617

[-- Attachment #2: Type: text/html, Size: 3683 bytes --]