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!nx02.iad01.newshosting.com!209.197.12.242.MISMATCH!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> <874o2vc7ab.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: <871uxubvwl.fsf@once.weird.com> Cancel-Lock: sha1:fa+//uW6OOB7IpXEMggaUSbtPJE= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 52 NNTP-Posting-Host: 24.67.98.78 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: newsfe09.iad 1310534330 24.67.98.78 (Wed, 13 Jul 2011 05:18:50 UTC) NNTP-Posting-Date: Wed, 13 Jul 2011 05:18:50 UTC Date: Tue, 12 Jul 2011 22:18:50 -0700 Xref: x330-a1.tempe.blueboxinc.net comp.std.c:723 Marcin Grzegorczyk writes: > Keith Thompson wrote: >> Marcin Grzegorczyk writes: > [...] >>> That's why I'd rather propose, instead of size, an enumeration with >>> distinct (implementation-defined) values for each valid type supported >>> by the implementation. A standardized macro could then map expression >>> type to an enumeration constant via the C1X generic selection construct >>> (i.e. no compiler magic needed); as an added benefit, the macro would >>> catch cases when a completely wrong type, like a floating-point or >>> structure type, is passed to a specifier that expects only integer types. >> >> But that wouldn't handle user-defined integer types, something that >> Greg's original proposal was *intended* to do. > > What user-defined types wouldn't it handle? Typedefs are just aliases > for existing types. Well, IFF there were some language magic something like typeof(), but which returned an enum usable in libc's printf(), i.e. such that printf() didn't have to be recompiled to use user-defined typedefs.... I.e. I to do what you're suggesting something new is needed in the language, even beyond typeof(). [a different form of typeof()]. What really matters to printf() though, from an implementation point of view, is just how many bytes to pull off the stack, and how many bits are significant in those bytes, and what and where the sign bit is, if any. The printf() implementation doesn't need to care what the actual type is, no matter whether it's a typedef or a base type. It might be easier to write a portable printf() if you can let the compiler put those bytes back into the same base type for printf() to use, but that's not _really_ important. My suggestion uses the non-standard typeof(), but only to figure out in a portable way whether an integer rvalue is signed or not. Adding an enum of base integer types might stretch the language definition too far for most folks, whereas typeof() is, I think, relatively well known and understood, and does nothing much more than provide a way of doing "dynamic" casts. Which reminds me -- I need to find out if anyone has figured out how the proposed "AIR" integer model is works with printf(), or if it even can. -- Greg A. Woods RoboHack living on the edge http://www.robohack.ca/