This is the mail archive of the
cygwin
mailing list for the Cygwin project.
"Incompatible" typedefs
- From: "Charles Wilson" <cygwin at cwilson dot fastmail dot fm>
- To: cygwin at cygwin dot com
- Date: Tue, 03 Feb 2009 12:06:49 -0500
- Subject: "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.
<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/