Path: csiph.com!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Spurious diagnostic messages Date: Sun, 02 Aug 2015 14:29:53 -0700 Organization: None to speak of Lines: 61 Message-ID: References: <874mn5ty3y.fsf@kst-u.example.com> <87egm8qis7.fsf@kst-u.example.com>

<45crratneenjh9ktjt1l8ioskb7ehrr8e5@4ax.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="29503"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19I4RqqDDKe/ktbUHgYrCOz" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:RYiQCPR8J/rjRvol7v+SsbnHs9w= sha1:sL9LqFq9dlpl2WxL16JmfAznHDs= Xref: csiph.com comp.lang.c:66741 Robert Wessel writes: > On Fri, 31 Jul 2015 09:01:02 -0700, Keith Thompson > wrote: [...] >>As I mentioned earlier, if binary literals are added to C, I think >>support should also be added to printf and scanf, probably using >>"%b". If this happens, C++ will eventually incorporate that feature >>as part of the C standard library. I suspect that would pressure >>the C++ committee to add similar support to . > > I disagree. There's little requirement to input and output binary > items. Binary literals in a program, OTOH, are quite useful in some > circumstances. We have decimal, octal, and hexadecimal constants, input, and output. Having decimal, octal, hexadecimal, and binary constants, but only decimal, octal, and hexadecimal input and output would be inconsistent. > OTOH, if you wanted to add binary to printf, in additional to the > existing octal and hex output, it's not a big deal, presumably would > not hurt anything (leaving aside just which escape sequence to use - > as has been pointed out "b" is taken), I just see little point. "b" isn't taken. What are you referring to? > As for the input functions, I also don't *personally* care too much, > since they're all pretty fundamentally broken anyway. Just the fact > that they *do* allow hex and octal input (for integers), pretty much > results in a mismatch with 99% of input specifications out there, > except for some where the use of those was introduced as an accident > (or bad decision), and we're stuck with it (the components of IPv4 > addresses, for example). The error handling on the scanf functions > also largely precludes their use. Some of the strto* functions are > fairly usable, although if the input is base-16 they can still be a > problem (and the strto* functions already support binary input). The fact that scanf() has undefined behavior on numeric overflow is a real problem. What's the problem with strto* and base 16? > But > adding binary support to the (other) input functions would likely > break things, no matter my opinion of the usefulness of those > functions. > > IOW, the C++ addition got it just right. There is a small incompatibility. Currently this: sscanf("0b11001001", "%i", &n); succeeds and sets n to 0; the 'b' and everything after it is ignored. With the proposed change, it would consume the entire string and set n to 201. I don't think that's a serious problem. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"