This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: "Incompatible" typedefs
Christopher Faylor wrote:
> On Tue, Feb 03, 2009 at 12:06:49PM -0500, Charles Wilson wrote:
>> I ran across an oddity in the cygwin headers today.
>
> This boils down to "What does linux do?". If we are doing something
> different then PTC.
Errr, it's a little weird. On linux, I have:
>From <sys/types.h>
typedef unsigned int u_int8_t __attribute__ ((__mode__ (__QI__)));
typedef unsigned int u_int16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned int u_int32_t __attribute__ ((__mode__ (__SI__)));
typedef unsigned int u_int64_t __attribute__ ((__mode__ (__DI__)));
>From <stdint.h>
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
>From <bits/types.h>
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
So it looks like everything is defined in terms of ANSI C types (int,
char, etc) without the intermediation that cygwin's headers use. So, all
of the [__]u[_]int32_t types are all 'unsigned int'.
I'm guessing that "__attribute__ ((__mode__ (__SI__)))" doesn't make
u_int32_t different than uint32_t. But apparently there is some heavy
duty compiler magic happening, because I would have thought that these two:
typedef unsigned int u_int16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned short int uint16_t;
are very different. But they are not (in that a variation of my test
case I posted earlier, emits no warnings with these two types).
I'm not sure what useful conclusions we can draw from looking at how
linux does it, Or maybe I just need some sleep.
--
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/