Bug 285098 – scanf() and strtoul() disagreeing on hex parsing

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description Martin Baute 2009-09-15 15:23:45 UTC]

Most likely an upstream glibc issue, but reporting this here first because I don't have a chance to test this against vanilla glibc and the GNU people ask to report with the distro used first.

(The URL given points to a forum post where I elaborate on the issue, including a test program. I also attached that test program here.)

Consider the scanf() conversion specifier "%x", which is defined by the C standard to match "an optionally signed hexadecimal integer, whose format is the same as expected for the subject sequence of the strtoul function with the value 16 for the base argument."

Note the reference to strtoul().

Now consider the calls:

sscanf( "0xz", "%x", &u );

and

strtoul( "0xz", &endptr, 16 );

Both functions parse the value as being zero, but sscanf() parses "0x", while strtoul() parses only the "0".

I am not quite sure what the correct behaviour should be (and newlib as well as MSVC have their own ideas, see referenced URL), but I don't think the results should differ...


Reproducible: Always

Steps to Reproduce:
1. Compile test program.
2. Run.

Actual Results:  
sscanf():  Value 0 - Consumed 2 - Next char z
strtoul(): Value 0 - Consumed 1 - Next char x


Expected Results:  
Not sure; either no match (0xz not being a hex number), or only parsing "0", but same result for both functions.

[Comment 1 Martin Baute 2009-09-15 15:24:15 UTC]

Created attachment 204207 [details]
Test program from the URL referenced.

[Comment 2 Martin Baute 2009-09-15 15:25:45 UTC]

Forgot to mention: Similar results happen when the same character sequence is parsed using the "%i" conversion specifier.