[PATCH] Fix type inconsistencies in stdint.h

Christopher Faylor cgf-use-the-mailinglist-please@cygwin.com
Tue Apr 7 14:53:00 GMT 2009

On Tue, Apr 07, 2009 at 06:56:53AM -0600, Eric Blake wrote:
>According to Christopher Faylor on 4/4/2009 12:24 AM:
>>> Because our stdint.h types are divergent from Linux, and changing them
>>> instead could cause yet another ABI break.
>>Why would changing uint32_t from 'unsigned long' to 'unsigned int'
>>break anything?  It looks to me like that is a disaster waiting to
>>happen if we ever provide a 64-bit port.
>If we ever provide a 64-bit port, then we are free to use #ifdef magic
>to select a different underlying type on 64-bit compiles than on 32-bit
>compiles.  In one sense, using a different type between the two builds
>will flush out coding bugs where the wrong type specifiers are used
>(for example, printf("%ld", (int32_t)val) should have been written
>printf("%"PRI32d, (int32_t)val).

Yes, of course, you could #ifdef these things.  If flushing out coding
bugs was a core requirement for Cygwin that would be an interesting
thing to do.  However our goal it really is quite the contrary.

We're suposed to make things easy to move between systems, warts and
all.  The goal is not to provide us with the opportunity to wag our
finger at hapless users in the Cygwin mailing who barely understand how
to run configure and make but nevertheless have a program that compiles
on linux and breaks on cygwin.  We're supposed to make things easier.

If people want to sanity check their code, they can buy a Plum Hall
or something.


More information about the Cygwin-patches mailing list