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

Eric Blake wrote:
> 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. 

Right. That was my understanding [*] which is why I assumed the cygwin
headers (in their 1.5 incarnation) needed some adjustment. But 1.7
already has the fix, so...

[*] "But on cygwin, unsigned long is unsigned, it is an integral
type,..." was my counterfactual argument against Dave's assertion that

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

are somehow obviously identical. (They ARE identical, but it is
unobvious). Spellings matter. Except when they don't.

>> [Dave's argument elided]
>> 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:
> and 6.7.2 Type specifiers:

These both agree with my earlier understanding. But then I still don't
understand how Dave's "fix" would fix anything:

typedef long int32_t
typedef unsigned long uint32_t

typedef long int int32_t
typedef unsigned long int uint32_t

(e.g as Dave said, "just add 'int' where it's missing" -- that is, ADD,
 not replace)

is a case of changing the spelling without changing the meaning at all;
that change would have zero effect and the definition of uint32_t would
STILL be different than u_int32_t, an "unsigned int". Right?

> 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.

Yep. Deep dark compiler magic.


Unsubscribe info:
Problem reports:

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