Mail Archives: cygwin/2009/02/03/12:07:07
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.
<g>
--
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/
- Raw text -