Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!ucsd!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.std.c
Subject: Re: Explain this sscanf behavior.
Keywords: sscanf ANSI
Message-ID: <25588@mimsy.umd.edu>
Date: 20 Jul 90 03:53:11 GMT
References: <1990Jul6.181830.2549@tc.fluke.COM> <13313@smoke.BRL.MIL>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 24

(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