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.
Created attachment 204207 [details] Test program from the URL referenced.
Forgot to mention: Similar results happen when the same character sequence is parsed using the "%i" conversion specifier.
