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]

"Incompatible" typedefs

I ran across an oddity in the cygwin headers today.

<machine/_types.h> has
typedef signed int __int32_t;
unsigned int __uint32_t;

<stdint.h> has
typedef long int32_t
typedef unsigned long uint32_t

<cygwin/types.h> has
typedef __uint32_t u_int32_t;

What this means is that these public types don't match (exactly)

uint32_t == unsigned long
u_int32_t == __uint32_t == unsigned int

Also, the public/private pair doesn't match (exactly)
int32_t == long
__int32_t == signed int

Now, on cygwin, there's no real harm. But from the C standard, long and
int are distinct types, so the following:

void func_a (u_int32_t * ptr) { ... stuff ... }
func_b (void)
  uint32_t x;
  func_a (&x);

raises a warning, without a typecast. But shouldn't "uint32_t" and
"u_int32_t" be identical in type, without requiring a typecast? (At
least in C. C++ is another story). If so, then what should be "fixed" in
the cygwin headers?  I'd bet stdint.h, since it is the odd man out --
but looking at its code it has a preference for "long" throughout. It
never uses "int". Plus, changing a fundamental typedef like this to
silence *my* warning, might cause thousands of other warnings from
existing code that expects &(unsigned long) to match &(uint32_t) without
a warning.

But my argument is, THAT client code is definitely non-portable to a
different platform where unsigned long might have a different number of
bits. But &(u_int32_t) ought to match &(uint32_t) without a warning on
ANY platform.

Or I could just add an explicit cast to my code, for the same reason.


Unsubscribe info:
Problem reports:

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