This is the mail archive of the
mailing list for the Cygwin project.
RE: cygwin g++ strictness
- From: "Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>
- To: <cygwin at cygwin dot com>
- Date: Fri, 31 Oct 2008 21:53:13 -0500
- Subject: RE: cygwin g++ strictness
- References: <490A30C8.email@example.com> <001601c93b31$a961b940$4001a8c0@mycomputer> <003e01c93b42$e92a17a0$4001a8c0@mycomputer> <490AE8A0.firstname.lastname@example.org> <001a01c93b4d$617de150$4001a8c0@mycomputer> <490AF1E3.email@example.com> <007401c93b56$ebcfa510$4001a8c0@mycomputer> <490B0084.firstname.lastname@example.org> <008a01c93b5a$9338d300$4001a8c0@mycomputer> <490B078B.email@example.com> <20081031135011.GB15518@calimero.vinschen.de> <490B21E9.firstname.lastname@example.org> <011601c93b6e$49bbb710$4001a8c0@mycomputer>
> From: John Emmas
> ----- Original Message -----
> From: "Peter Rosin"
> Sent: 31 October 2008 15:19
> Subject: Re: cygwin g++ strictness
> > I some projects I'm involved with there's quite a bit of
> the following:
> > [...]
> > int.c:6: warning: int format, int32_t arg (arg 2)
> I must confess, this has been a source of irritation for me
> too but at least it doesn't stop the build. It does however
> bring us back to the fundamental question - when programming
> like this:-
> int32_t i = 32;
> printf("%d", i);
> is it reasonable for a programmer to assume that a type
> declared as int32_t will be compatible with "%d" when
> building for a 32-bit platform?
No. The only reasonable assumption to make in a case like this is that if
you don't do it right, you'll end up doing it over. "%d" means "int". You
use that to print an int. If you have something that is not an int, and you
want to print it, then you have exactly two reasonable choices:
1. Cast whatever you have to an int, then use "%d" to print it.
2. Use the proper format specifier, and pass whatever you have to directly
printf() (i.e. un-casted).
In this particular instance, #1 is the wrong choice, since you have no
guarantee that an int can contain an int32_t. You are left with #2, which
is not only the correct answer, but the path of least resistance as well.
> I'd be surprised if there's
> a programmer amongst us who can honestly say he wouldn't have
> made that assumption.
Be surprised ;-).
Gary R. Van Sickle
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html