Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!samsung!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: ANSI draft interpretation questions
Message-ID: <11911@smoke.BRL.MIL>
Date: 8 Jan 90 22:12:38 GMT
References: <21623@mimsy.umd.edu> <11879@smoke.BRL.MIL> <21675@mimsy.umd.edu> <11897@smoke.BRL.MIL> <21690@mimsy.umd.edu> <15591@haddock.ima.isc.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 42

In article <15591@haddock.ima.isc.com> karl@haddock.ima.isc.com (Karl Heuer) writes:
>In article <21690@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>>[So apparently scanf() requires at least three bytes of lookahead or pushback
>>so that it can recover from "1.2e-x", which assigns 1.2 and leaves "e-x" in
>>the input stream.]
>No no no.  That may be the morally correct action, but it's not what the
>Standard says.  Doug was mistaken on this point.
>4.9.6.2 says "If conversion terminates on a conflicting input character, the
>offending input character is left unread".  In the example, the "x" is the
>first conflicting input character, so only it remains unread; the characters
>"1.2e-" are consumed (and the conversion fails, since it does not form a valid
>floating-point number).

Again, I think this is a case of focusing too narrowly on only a portion
of the full Standard.  Two pages earlier, an "input item" is carefully
defined as the LONGEST MATCHING sequence of input characters, etc. and
that the FIRST CHARACTER after the input item remains unread.  I think
too much is being read into the term "conflicting input character".

By the way, this does conflict with a response given to David Hough
during the third public review, as well as the example.  Therefore, it
seems appropriate for submission to X3 as an interpretation issue
requiring clarification.  Perhaps our response was incorrect (not the
first time that happened), or perhaps my reading of the Standard is.
Anyhow, they're inconsistent.

>The examples on page 139 of the Dec88 Draft clearly demonstrate that a format
>beginning with "%f" matches zero items when presented with "100ergs", because
>`"100e" fails to match "%f"'.  Moreover, the Rationale says that "One-
>character pushback is sufficient for the implementation of |fscanf|.  Given
>the invalid field `-.x', the characters `-.' are not pushed back" and "if a
>`flawed field' is detected, no value is stored for the corresponding
>argument".
>I think the intent of the Committee is clear.

Unfortunately for this argument, one of the unwritten guiding principles
of the fprintf and fscanf specs was that they should closely follow what
the AT&T UNIX System V implementation actually DID, and I just tested
that and found that %f does match the "100" part of "100ergs", contrary
to the example but in agreement with my interpretation of the Standard.
So it's not so clear that we got this right.  (Note that the example
contained a late editing change, which makes it suspect in my opinion.)