[comp.lang.c] Explain this sscanf behavior.

mason@tc.fluke.COM (Nick Mason) (07/07/90)

What should sscanf do with the following?  Does anyone
have the ANSI standard and shed some light on the following?

I would like "hard" replies, not "I think it should ....".

Thanks in advance.

Given:

	char *buf="123";
	char *str="123x";

	int  a, b, x;

	b = -99;

	x = sscanf(str, "%d%n", &a, &b);

	printf("x=%d, a=%d, b=%d\n",x,a,b);

	x = sscanf(buf, "%d%n", &a, &b);

	printf("x=%d, a=%d, b=%d\n",x,a,b);


What is the CORRECT output according to the standard???

I tried this with 3 different compilers and got the following:

compiler A:

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

compiler B:

	x=1   a=123  b=3
	x=1   a=123  b=4  <-- yes 4.

compiler C:

	x=1  a=123  b=3
	x=1  a=123  b= -99



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


Nick.

daniels@tle.enet.dec.com (Bradford R. Daniels) (07/07/90)

> 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...

kdq@demott.COM (Kevin D. Quitt) (07/08/90)

In article <1990Jul6.181830.2549@tc.fluke.COM> mason@tc.fluke.COM (Nick Mason) writes:
>
>I tried this with 3 different compilers and got the following:
>
>compiler A:
>
>	x=1   a=123  b=3
>	x=1   a=123  b=3
>
>compiler B:
>
>	x=1   a=123  b=3
>	x=1   a=123  b=4  <-- yes 4.
>
>compiler C:
>
>	x=1  a=123  b=3
>	x=1  a=123  b= -99
>

    I'm confused by example C: where did it get the old value of b? BTW,
Microsoft C and cc on Motorola Delta 3x00 agree with A, and gnu's gcc
coredumps. 

-- 
 _
Kevin D. Quitt         demott!kdq   kdq@demott.com
DeMott Electronics Co. 14707 Keswick St.   Van Nuys, CA 91405-1266
VOICE (818) 988-4975   FAX (818) 997-1190  MODEM (818) 997-4496 PEP last

                96.37% of all statistics are made up.

gwyn@smoke.BRL.MIL (Doug Gwyn) (07/08/90)

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.

inst182@tuvie (Inst.f.Techn.Informatik) (07/10/90)

To add a new variant, on a DECstation 3100 (Ultrix 2.1) both cc (1.31) and
gcc (1.37) give the following results:

x=2, a=123, b=3
x=1, a=123, b=3

(no coredumps)