X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 	tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: sourceware.org
Message-ID: <49BD152C.5000506@cwilson.fastmail.fm>
Date: Sun, 15 Mar 2009 10:48:12 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.19) Gecko/20081209 Thunderbird/2.0.0.19 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: long unsigned int vs. uint32_t again
References: <49BC958D DOT 2080306 AT cwilson DOT fastmail DOT fm> <416096c60903150132g2f33c3a4od84b1122dcf4e92e AT mail DOT gmail DOT com>
In-Reply-To: <416096c60903150132g2f33c3a4od84b1122dcf4e92e@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
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

Andy Koppe wrote:
> Chuck wrote:
>> cygwin's <inttypes.h> has:
>> #define PRIu32 "lu"
>>
>> and <stdint.h> has
>> typedef unsigned int uint32_t;
>>
>> Is it possible that our inttypes.h should be changed, to use "u" for 8, 16, and 32 bits?
> 
> Yep, I'd say so.

Linux agrees with you.  Its inttypes.h has:

# if __WORDSIZE == 64
#  define __PRI64_PREFIX        "l"
#  define __PRIPTR_PREFIX       "l"
# else
#  define __PRI64_PREFIX        "ll"
#  define __PRIPTR_PREFIX
# endif

...

# define PRIu8          "u"
# define PRIu16         "u"
# define PRIu32         "u"
# define PRIu64         __PRI64_PREFIX "u"

and similar, throughout [*]. Fortunately, this file is from src/winsup,
not src/newlib, so we don't have to worry about the impact of any change
on other platforms supported by newlib.

Should I prepare a patch (and I assume we're not worried yet about
WORDSIZE==64)?

>>  Or is gcc's -Wformat=2 in 3.4.4 just too strict here -- and should be checking
>> the actual bitwidths of types against the formats, before assuming that
>> "lu" doesn't match uint32_t?
> 
> No. "long" and "int" are different types, and ignoring this would just
> store up trouble for when code is ported to platforms with 64-bit
> longs.

Ack.

--
Chuck


[*] The *FAST* macros follow a different pattern:

# define PRIuFAST8      "u"
# define PRIuFAST16     __PRIPTR_PREFIX "u"
# define PRIuFAST32     __PRIPTR_PREFIX "u"
# define PRIuFAST64     __PRI64_PREFIX "u"

because stdint.h has this (and similar, throughout):

typedef unsigned char           uint_fast8_t;
#if __WORDSIZE == 64
typedef unsigned long int       uint_fast16_t;
typedef unsigned long int       uint_fast32_t;
typedef unsigned long int       uint_fast64_t;
#else
typedef unsigned int            uint_fast16_t;
typedef unsigned int            uint_fast32_t;
__extension__
typedef unsigned long long int  uint_fast64_t;
#endif


--
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/