X-Recipient: archive-cygwin@delorie.com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; q=dns; s=
	default; b=Abw0TOGWC47S7yJUIhQ9KdQa9BD2Td7fMiVJIZUas239Jnw8WmuFJ
	q356WKm3BZoG4GuowXHhDaDNvVkFdmqXz7yxm4aiVLudRQRsS/5BW33UU3yrQU7G
	1RzavmcUARALhF932zL3p09cnbLzFnlhcr5KUwIhj1PUpzJ/UzrB2I=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:date:from:to:subject:message-id:reply-to
	:references:mime-version:content-type:in-reply-to; s=default;
	 bh=wSsffXftTxQeFe1THvTn7jfNBaI=; b=Uu+2BTlxUTgMYONXRDy/HWrUcmh9
	cSEYJm76/n5opZYk57bMH8yMb0i5RKKadKqV3pKwFvvWCD0XMEhx1OyDZR5z5wDS
	ecbSVEiVLvvzGOsKy4l7VvLQOfXH/eqsSaSODw9iNEAPVW/GhujO0J7J2GEcVhDG
	OoQkxb8mLzPKYYU=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe@cygwin.com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-help@cygwin.com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Delivered-To: mailing list cygwin@cygwin.com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2
X-HELO: calimero.vinschen.de
Date: Tue, 28 Apr 2015 12:45:47 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Incorrect compile warning, possible bug in inttypes.h
Message-ID: <20150428104547.GZ3657@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <261055273.5586453.1430175146814.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="kM4gEFU/49KOGupy"
Content-Disposition: inline
In-Reply-To: <261055273.5586453.1430175146814.JavaMail.yahoo@mail.yahoo.com>
User-Agent: Mutt/1.5.23 (2014-03-12)

--kM4gEFU/49KOGupy
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Cary,

On Apr 27 22:52, Cary R. wrote:
> The following code:
>=20
> #include <stdio.h>
> #include <inttypes.h>
>=20
> int main()
> {
>         int32_t ival =3D 1;
>         uint32_t uval =3D 2;
>=20
>         printf("int =3D %"PRId32", uint =3D %"PRIu32".\n", ival, uval);
>         return 0;
> }
>=20
>=20
> when compiled with either gcc or clang on a 32-bit system and with the -W=
all flag produces the following warnings:
>=20
> tmp.c: In function =E2=80=98main=E2=80=99:
> tmp.c:9:5: warning: format =E2=80=98%ld=E2=80=99 expects argument of type=
 =E2=80=98long int=E2=80=99, but argument 2 has type =E2=80=98int32_t=E2=80=
=99 [-Wformat=3D]
>          printf("int =3D %"PRId32", uint =3D %"PRIu32".\n", ival, uval);
>          ^
> tmp.c:9:5: warning: format =E2=80=98%lu=E2=80=99 expects argument of type=
 =E2=80=98long unsigned int=E2=80=99, but argument 3 has type =E2=80=98uint=
32_t=E2=80=99 [-Wformat=3D]
> tmp.c:9:5: warning: format =E2=80=98%ld=E2=80=99 expects argument of type=
 =E2=80=98long int=E2=80=99, but argument 2 has type =E2=80=98int32_t=E2=80=
=99 [-Wformat=3D]
> tmp.c:9:5: warning: format =E2=80=98%lu=E2=80=99 expects argument of type=
 =E2=80=98long unsigned int=E2=80=99, but argument 3 has type =E2=80=98uint=
32_t=E2=80=99 [-Wformat=3D]
>=20
> I'm not sure why the double report for this, but both gcc and clang do
> the same thing. This looks to be an issue that is generated because a
> long is 32 bits on a 32-bit system and in inttypes.h __have_long32 is
> likely defined and that is forcing the use of the 'l' formats when
> that is incorrect for at least these two 32 bit types.

That looks like the culprit, yes.  This is part of the newlib changes to
stdint.h/inttypes.h, and this is apparently a problem.  Just because
long is a 32 bit type doesn't mean it's the base type of int32_t/uint32_t.
What bugs me most is that I tried to test the changes and failed to see
this problem.  Grr.

I'll discuss this on the newlib mailing list.


Thanks,
Corinna

--=20
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--kM4gEFU/49KOGupy
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJVP2TbAAoJEPU2Bp2uRE+gnJgP/0SXmUVgZQxAizWLXPw3JPip
SujB/mBjjj6iHyVVDcZ7leUl5iArWePn9M8dAWzmnL1wsJ38gqcW3PdriTmT5V3b
s0AwYrj/NUapqPsm8M94je8IFrGePxpta8/S4FbfLFHFMiziUiLwy+608LwNYgZ1
Cqu6qr/JbX9phaqyoVeLIa6phN6UpPlfEBcZVM7HTQjBGoa0ViwjpD9mXo23rM61
f42k9TrwR3VjwHFneDm1K+wJu3sfBQIeUodFKnWd+82nV1/3ak+c2fr92D+CdLjg
BHfTcVVbb6IVcXBgnEgqL0EfIFKMQgQXePjdcgU8yZm4yimTRokTzBWcRJRA9Mae
teoo7q8pkOyEf/bbWdV8Ulm889u8Yp/DebnJlYvQ8egFZr57GB3tk41i+U46y8Vf
+j+YicWphkv60BT1+2TuiXap3fcbYInFFc+89BN3BbQHmHz0AT/i3y5RiYnXkIro
FL9aUy+aCnerxQ6yq2FUWDN7kjR+lGyDoc94iZ+wDn6cEHzkeYzaeydspB6uM6Q4
yoFenDWmzSRawJf+W7ayb9CKLig03lA9Pou/AOC5rUTcfwDvGth0y/qKOROox5qI
WkpLhRkqFHybYNuhvKcOGK7EwpuXp+kHQxXf5Z+FwGCEoYbJ2gP090k2d825X1tl
cPZ/lfzTiKCsd3AKUPZ9
=RHPF
-----END PGP SIGNATURE-----

--kM4gEFU/49KOGupy--
