X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 	tests=AWL,BAYES_20,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-Id: <1233680809.17414.1298297091@webmail.messagingengine.com>
From: "Charles Wilson" <cygwin AT cwilson DOT fastmail DOT fm>
To: cygwin AT cygwin DOT com
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="ISO-8859-1"
MIME-Version: 1.0
Subject: "Incompatible" typedefs
Date: Tue, 03 Feb 2009 12:06:49 -0500
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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/