This is the mail archive of the
cygwin
mailing list for the Cygwin project.
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:
[snipped]
> and 6.7.2 Type specifiers:
[snipped]
These both agree with my earlier understanding. But then I still don't
understand how Dave's "fix" would fix anything:
Changing:
typedef long int32_t
typedef unsigned long uint32_t
To:
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.
--
Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/