delorie.com/archives/browse.cgi | search |
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> |
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/
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |