ANSI draft interpretation questions

[Karl Heuer]

In article <21690 at mimsy.umd.edu> chris at 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 at haddock.isc.com or ima!haddock!karl), The Walking Lint