Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.std.c
Subject: Re: ANSI draft interpretation questions
Summary: scanf does *not* do error recovery
Message-ID: <15591@haddock.ima.isc.com>
Date: 8 Jan 90 19:03:34 GMT
References: <21623@mimsy.umd.edu> <11879@smoke.BRL.MIL> <21675@mimsy.umd.edu> <11897@smoke.BRL.MIL> <21690@mimsy.umd.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 39

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).

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.


>Incidentally, it is not clear to me whether the standard requires
>the following to work.  [Code equivalent to the following:]
>	c = getchar();  assert(c == 'h');
>	r = scanf(" %n", &n);  assert(r == 0 && n == 0);
>	ungetc('h', stdin);  /* can this fail? */
>If n is zero, we know the scanf() did not consume any characters.  We
>may therefore be required to allow the `h' to be pushed back.  I am not
>sure.

I believe this is exactly what the Committee intended to legalize with its
insistence that scanf is "not allowed to consume the ungetc slot".  Yes, the
traditional Unix implementation is non-conforming.  It will have to be fixed.

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