Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.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!newsfe19.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> <87box6hdaj.fsf@once.weird.com> <4E155790.7020101@loria.fr> 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: <87vcvdg5j7.fsf@once.weird.com> Cancel-Lock: sha1:qXqnb83yzrmLnDfvU6alW1wWPpg= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 83 NNTP-Posting-Host: 24.67.98.78 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: newsfe19.iad 1310073085 24.67.98.78 (Thu, 07 Jul 2011 21:11:25 UTC) NNTP-Posting-Date: Thu, 07 Jul 2011 21:11:25 UTC Date: Thu, 07 Jul 2011 14:11:24 -0700 Xref: x330-a1.tempe.blueboxinc.net comp.std.c:619 Jens Gustedt writes: > > Am 07.07.2011 07:26, schrieb Greg A. Woods: >> This (i.e. really all of stdarg) is the one place where the true >> low-level nature of C still shines through with unbridled enthusiasm. >> This isn't necessarily a bad thing, but we have never really truly done >> anything useful to help at least make the worst parts, for the worst >> standard functions, any better. > > But this is exactly where the problem is, not printf per se, but > stdarg. The underlying problem, yes, but not the _real_ problem. The real problem is the one we see in questions from students and practitioners every day, and that is with the confusion over integer size and sign vs. printf() and scanf() format specifiers. > The promotion rules are simply archaic and of no good, nowadays. No, that's not right _at_ _all_. > All > the problem would go away if all integer type parameters would be > promoted to [u]intmax_t, all data pointer types to void* and all > floating types to long double. So, you want new, different, promotion rules, not to get rid of the promotion rules. Sorry for my language, but that would be stupid and would break WAY too much existing code, and it would raise ire from everyone seriously concerned with performance. We have already had more than enough stupidity in more modern C standards which has caused well enough breakage already in existing code. There's nothing really wrong with the current promotion rules for function parameters, though ideally they should be a little more compatible with the original language, not a slight incompatible variation and invention. They're still confusing of course, but that's the way they are. > I don't think that this has anything to do with "low-level" nature of > C, but with a wrong design choice that we carry around as a legacy. By "low-level" I mean by the way C does not pass type information to the caller (esp. for variable numbers of parameters) -- i.e. parameters are stuffed on the stack or in registers by the caller and it's up to the receiver to know what to expect. This is dealt with in printf() and scanf(), as well as in every other similar real-world situation like this: first let me tell you how I'm going to tell you what I'm going to tell you. Unfortunately though printf() doesn't do that very well sometimes, at least not for human programmers, and even the compiler can't help other than with non-standard non-required warnings in the case of integer types that purposefully hide their width and sign from the programmer. My proposal is simply to add further hints about the parameters which follow. I.e. to extend what is already done, and to do so in a reliable and human-friendly way. If you want to print(scan) a number, but you don't know what the underlying type is, then you just use "%Si" and INTPARAM(ival) and you will explicitly tell printf()/scanf() what type to expect. Folks who worry about the cost of pushing three ints for every int don't have to use the 'S' flag. I don't want to take away anything -- just add something new and very simple in an upwardly compatible way. > Not that I am against it, but what you are proposing is just a cure > for a symptom, one of many symptoms for that particular legacy. I'm just trying to suggest a possible fix for what I've seen over the past 20 years as a very common problem, as opposed to trying to change any very important aspect of the fundamental language like you've suggested doing. -- Greg A. Woods RoboHack living on the edge http://www.robohack.ca/