This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: "Incompatible" typedefs

Charles Wilson <cygwin <at>> writes:

> But, at the risk of extending this thread -- I do have a question. Is
> there really a difference between
> short    vs.    short int
> long     vs.    long int
> unsigned vs.    unsigned int
> signed   vs.    signed int

No difference in any of those examples; however, I personally like the 
forms 'short int', 'long int', 'unsigned int', and 'int'.

> (etc, other combinations of modifiers with and without 'int')

The difference you are running into is the fact that 'int' and 'long int' (or 
alternately spelled, 'int' and 'long') are distinct types, even if they both 
occupy 32 bits and are both signed.  Likewise, 'unsigned long int' 
and 'unsigned int' (or alternately spelled, 'unsigned long' and 'unsigned') are 
distinct types, even if both occupy 32 bits and are both unsigned.  It is this 
difference that is tripping up 1.5 users, because the headers are using 
distinct types where they shouldn't be.  Also, 'signed int' and 'int' are 
identical, but 'char', 'unsigned char', and 'signed char' are three distinct 

> Your argument seems to imply that there is. I always thought that the
> 'int' was implied when only the size (or signedness) was specified, and
> that the types were exactly identical. No? Reference, please?

How about C99 6.2.5 Types:

| There are five standard signed integer types, designated as signed char,
| short int, int, long int, and long long int. (These and other types may be
| designated in several additional ways, as described in 6.7.2.)

| For each of the signed integer types, there is a corresponding (but
| different) unsigned integer type (designated with the keyword unsigned)
| that uses the same amount of storage (including sign information) and has
| the same alignment requirements. The type _Bool and the unsigned integer
| types that correspond to the standard signed integer types are the standard
| unsigned integer types.

and 6.7.2 Type specifiers:

| Each list of type specifiers shall be one of the following sets (delimited
| by commas, when there is more than one set on a line); the type specifiers
| may occur in any order

| â char
| â signed char
| â unsigned char
| â short, signed short, short int, or signed short int
| â unsigned short, or unsigned short int
| â int, signed, or signed int
| â unsigned, or unsigned int
| â long, signed long, long int, or signed long int
| â unsigned long, or unsigned long int
| â long long, signed long long, long long int, or signed long long int
| â unsigned long long, or unsigned long long int

And with this knowledge, you then get to play with what gcc means by

>> typedef unsigned int u_int16_t __attribute__ ((__mode__ (__HI__)));
>> typedef unsigned short int uint16_t;

They are based on two different base types (unsigned int vs. unsigned short 
int), but the presence of __attribute__ means that you are outside the realm of 
C99, so it is up to the compiler whether u_int16_t is effectively the same 
class as 'unsigned short int' or whether it behaves more like an 'unsigned int' 
truncated to 16 bits.  And that's where I don't know the right answer.

Eric Blake

Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]