And yet another scanf interpretation question

[Doug Gwyn]

In article <21625 at mimsy.umd.edu> chris at mimsy.umd.edu (Chris Torek) writes:
>	+1.2345e		[missing exponent digits]

The characters through '5' are consumed and 'e' remains "unread in the
input stream", which in practice means pushed-back or its moral
equivalent.  (If available, peek-ahead could be employed to avoid
having to push anything back.  It amounts to the same thing EXCEPT
for possible interaction with ungetc(), which is an ugly can of
worms.  The Standard deliberately does not consider these "unread"
characters as pushed-back in the sense of ungetc().)

>The draft goes on to say, however, that `If conversion terminates on
>a conflicting input character, the offending input character is left
>unread in the input stream.'  This can only be meant to imply `conflicting
>with a literal character from the format string', not `conflicting with
>the format required by a conversion such as %f'.

No; see also line 35 on page 136 of the December 1988 draft.
It really does mean that the peeked-ahead characters that failed to
match remain "unread".

>Note that the most useful answer---that the entire malformed floating
>point number remains unconsumed---requires mandating an arbitrary amount
>of pushback (or, equivalently, lookahead): the `floating point number'
>    1.111111111111111111111111111111111111111111111111111111111e-
>looks just fine until the lack of a digit following the `-' shows up.

No, the string up to the 'e' is of the expected form and must be
properly converted.  Only three characters of peek-ahead suffice to
detect that the apparent exponent part really isn't an exponent part.