🚀 go-pugleaf

(code in question: `sscanf("123", "%d%n", &a, &b)')

In article <13313@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>You've uncovered an interesting feature:  Although the %n specifier
>does not consume input, it can still have an "input failure" when
>EOF was encountered during preceding conversions that matched non-
>empty sequences.

Although the wording in the standard can be read to mean `%n fails with
an input failure if the stream is at EOF' (which would cause b to be
unmodified), I cannot believe that this was the intended behaviour.  It
seems to me that only conversions that require input should be able to
cause input failures, and I think the standard could be interpreted
this way too.

>P.S.  This is not an official interpretation; if it bothers you,
>please send an official request for interpretation to CBEMA X3.

Someone please do so.

(who me? :-) )
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris