Xref: utzoo comp.std.c:3354 comp.lang.c:30172
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!bacchus.pa.dec.com!decatl!shlump.nac.dec.com!tle.enet.dec.com!daniels
From: daniels@tle.enet.dec.com (Bradford R. Daniels)
Newsgroups: comp.std.c,comp.lang.c
Subject: Re: Explain this sscanf behavior.
Keywords: sscanf ANSI
Message-ID: <13168@shlump.nac.dec.com>
Date: 6 Jul 90 22:17:06 GMT
References: <1990Jul6.181830.2549@tc.fluke.COM>
Sender: newsdaemon@shlump.nac.dec.com
Reply-To: daniels@tle.enet.dec.com (Bradford R. Daniels)
Followup-To: comp.std.c
Organization: Digital Equipment Corporation
Lines: 32

> compiler A:

> 	x=1   a=123  b=3
> 	x=1   a=123  b=3

This is the correct result.

> compiler B:
> 	x=1   a=123  b=3
> 	x=1   a=123  b=4  <-- yes 4.

This is clearly wrong, since there aren't even 4 characters in the string...

> compiler C:
> 	x=1  a=123  b=3
> 	x=1  a=123  b= -99

This is also wrong, since %n does not consume any input, and so the
lack of input should not cause it to fail.

> I'm confused????!!!!! Compiler C is "100% ANSI compatible".????

ANSI compatible does not mean bug free.  This behavior is a bug, and
I think I see how it's happening...  In fact, I think I'll go make sure
my RTL doesn't have the same problem...

- Brad

-----------------------------------------------------------------
Brad Daniels			|  Digital Equipment Corp. almost
DEC Software Devo		|  definitely wouldn't approve of
"VAX C RTL Whipping Boy"	|  anything I say here...