Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!nx01.iad01.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe09.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> <87mxgpe84b.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: <878vs8dm52.fsf@once.weird.com> Cancel-Lock: sha1:Blx4dvgzXiGxEo2SwdAUJwCMv2g= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 56 NNTP-Posting-Host: 24.67.98.78 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: newsfe09.iad 1310191530 24.67.98.78 (Sat, 09 Jul 2011 06:05:30 UTC) NNTP-Posting-Date: Sat, 09 Jul 2011 06:05:30 UTC Date: Fri, 08 Jul 2011 23:05:29 -0700 Xref: x330-a1.tempe.blueboxinc.net comp.std.c:669 James Kuyper writes: > > On 07/07/2011 11:58 PM, Greg A. Woods wrote: >> James Kuyper writes: >>> >>> The right way to warn about mismatches: only warn when there's an actual >>> mismatch. >> >> It is an "actual" mis-match -- at least if you intend your code to be >> portable. > > For every conforming implementation of C, PRI32d must be a correct match > to whichever type int32_t represents in that implementation. While > implementations are permitted to issue diagnostics for any reason they > like ("warning: identifiers containing 'z' make me feel fuzzy!"), an > implementation which diagnoses the correct match that PRI32d must have > with int32_t has low QoI because it's wasting the developer's time. I'm explicitly not talking about the ideal world where every implementation is conforming! This is an issue of application in the real-world, of helping to make real-world code work in real-world environments. > Then why are they using int32_t? They only need the PRI* macros if they > choose to use the new size-named types. Because people love to use new features, but when those features are not really well documented, and when they can easily lead to such problems, those features might cause more harm than good. Read some real code (e.g. do some internet searches on *PRI* and *FMT* to find examples) and see for yourself. >>> Well, of course not. For that you use >>> printf("seconds since epoch:%.0f\n", difftime(value,epoch)); >> >> Decades of unix tradition flushed down the drain by C99. :-) > > What tradition are you talking about? The tradition of course that time_t is, always has been, and always will be, an _integer_ number of seconds since the epoch. > What you've specified is not something I can see any point in printing > out, Assumptions, assumptions, assumptions! You know what they say about assumptions! :-) -- Greg A. Woods RoboHack living on the edge http://www.robohack.ca/