Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe22.iad.POSTED!00000000!not-for-mail Newsgroups: comp.std.c Subject: Re: PRI* considered harmful User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (berkeley-unix) References: <87mxgqhk3x.fsf@once.weird.com> <8762ndhnfs.fsf@once.weird.com> <87oc15g10i.fsf@once.weird.com> <87zkkpef5z.fsf@once.weird.com> From: "Greg A. Woods" X-Face: .}E4CW({2'v<\JefgY&(9#RJD?~_7.KTC$+RklqwlB/<)^)~X0i*J?m)SXpHA8'9FHn5Fz*eVTH5=_C>]XK#"dLOyD`#tbEh1_8v-hwwR{.X)+b-!\4mM] 1HqG#"@VSI$1MNvRk\4>qsCclW|Ns4V/2poz=gS-+~m8\%5eVq]a\3.>T>U/f8A Message-ID: <87r560c6pp.fsf@once.weird.com> Cancel-Lock: sha1:IxZAUg+KS/dJQ4Hkb7S1PrnT5Do= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 60 NNTP-Posting-Host: 24.67.98.78 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: newsfe22.iad 1310192643 24.67.98.78 (Sat, 09 Jul 2011 06:24:03 UTC) NNTP-Posting-Date: Sat, 09 Jul 2011 06:24:03 UTC Date: Fri, 08 Jul 2011 23:24:02 -0700 Xref: x330-a1.tempe.blueboxinc.net comp.std.c:671 Keith Thompson writes: > > So don't use them. It's not _my_ problem -- I try not to use the PRI* macros. :-) > On my system (Ubuntu 11.04, gcc 4.5.2, glibc 2.13), int32_t is a > typedef for int, and PRId32 is defined as "d". good to know > Can you cite a specific real-world system where the definitions of > int32_t and PRId32 are inconsistent? Can you demonstrate that this > program: > > #include > #include > int main(void) > { > int32_t x = 42; > printf("x = %" PRId32 "\n", x); > return 0; > } > > triggers a warning about the format string? If it's a big a problem > as you say it is, that shouldn't be difficult. It's just that I've seen many references to PRId32 on Linux, including online manual pages, which show it as "ld". >> Thus my suggestion of enhancing printf() instead of trying to suggest >> that the standard provide more PRI* like macros. Let's get rid of the >> problem entirely, or at least provide a truely safe and innovative >> solution for those who would prefer a better way. > > You know what? I might actually agree with whatever point you're > trying to make, if I can figure out just what it is. I've never > found any use for the PRI* macros myself. But your underlying point > is obscured by your claims about problems with the PRI* macros that, > as far as I can tell, do not actually exist. Well, for me personally (as opposed to all those I see trying to use PRI* poorly), the problem extends to every other typedef name that one might define in any application which one hopes to be portable and easy to maintain. The reason I've harped on PRI* is that their existance would also be entirerly unnecessary were something like my proposal implemented, and because there are now countless examples of people trying vainly to emulate the PRI* macros for their own use, but even more often getting it entirely wrong. -- Greg A. Woods RoboHack living on the edge http://www.robohack.ca/