Xref: utzoo comp.std.c:3356 comp.lang.c:30194
Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: Explain this sscanf behavior.
Keywords: sscanf ANSI
Message-ID: <13313@smoke.BRL.MIL>
Date: 8 Jul 90 04:13:15 GMT
References: <1990Jul6.181830.2549@tc.fluke.COM>
Followup-To: comp.std.c
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 22

In article <1990Jul6.181830.2549@tc.fluke.COM> mason@tc.fluke.COM (Nick Mason) writes:
>	int  a, b = -99, x;
>	x = sscanf("123x", "%d%n", &a, &b);
>	printf("x=%d, a=%d, b=%d\n",x,a,b);
>	x = sscanf("123", "%d%n", &a, &b);
>	printf("x=%d, a=%d, b=%d\n",x,a,b);
>What is the CORRECT output according to the standard???

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.

>compiler C:
>	x=1  a=123  b=3
>	x=1  a=123  b= -99
>I'm confused????!!!!! Compiler C is "100% ANSI compatible".????

It might be; it did return the right answer in this particular case.

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