Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: C Community's Cavalier Attitude On Software Reliability
Message-ID: <16056@haddock.ima.isc.com>
Date: 28 Feb 90 20:30:07 GMT
References: <8147@hubcap.clemson.edu> <1990Feb26.234321.1072@utzoo.uucp> <16046@haddock.ima.isc.com> <2922@goanna.oz.au>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 31

In article <2922@goanna.oz.au> ok@goanna.oz.au (Richard O'keefe) writes:
>karl@haddock.ima.isc.com (Karl Heuer) wrote:
>>Fixed in ANSI C, via the "%n" directive.
>
>It is a great improvement that this is possible, but it really doesn't
>count as "DIRECTLY determinable".

A quibble.

>One very simple change would have done:  _add_ a new suppression
>character, say "#".  %#<fmt> would act exactly like %*<fmt> except
>that it would be counted.

My own idea was to add a new format *specifier*, say "%;", whose whole purpose
would be to increment the return value.  This is a conceptually simpler
change, and is equally powerful (your "%#d" is my "%*d%;", and you don't need
to play around with zero-width fields if the increment is all you want).  Note
also that the typical use would be to put a single "%;" at the end of the
format, to verify that the whole thing worked (which can also be done with
"%n"); normally one doesn't care about partial success.

>Presumably the ANSI C committee considered and rejected some such proposal.

I believe it was generally recognized that scanf() is a crock which continues
to exist only for backward compatibility.

>It doesn't bother me, because [it's usually better not to use scanf anyway]

Agree.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint