question about scanf

[Mtt]

I have been using C for a while, but I encountered this today and its behavior is different from what I expected.

scanf("%d,%d",&d1,&d2);
this matches "1,2" as expected but it also matches "1, 2", why?
Since it matches "1, 2" I thought maybe its because scanf ignores whitespace before any non whitespace character, but it does not match "1 , 2". So scanf ignores the whitespace before 2 but not the whitespace before ,? Why is this happening?

 

[mrjminer]

I don't know much C, barely used it for a month over 10 years ago. I will take a shot in the dark.

Going off: http://www.cplusplus.com/reference/cstdio/scanf/

Whitespace character: the function will read and ignore any whitespace characters encountered before the next non-whitespace character (whitespace characters include spaces, newline and tab characters -- see isspace). A single whitespace in the format string validates any quantity of whitespace characters extracted from the stream (including none).

I am presuming that text I quoted only actually applies to the text immediately preceding what that page describes as the "format specifier," however, based on what you wrote. The "," character appears to be part of the format string, like a separator, so that may be why it doesn't apply to it. Or it could just be something they chose to do internally due to optimizations and not trimming the right side of the value. Or just because a lot of older core functions operate based on how things are typically done IRL (ie: like when you list numbers, you don't put a space before the comma).

If my thought is right, then " 1, 2" should work.

And "1, 2 " shouldn't according to the quote since the space is after the 2 (but they may just do a general "trim()" on the value internally or something too to let that pass). You might be able to test that further with the float scanf format specifier (which uses 3 numbers.. like so "1, 2 , 3" wouldn't work but "1, 2, 3 " would if that is the case).

 

[Mtt]

I don't know much C, barely used it for a month over 10 years ago. I will take a shot in the dark.

Going off: http://www.cplusplus.com/reference/cstdio/scanf/
I am presuming that text I quoted only actually applies to the text immediately preceding what that page describes as the "format specifier," however, based on what you wrote. The "," character appears to be part of the format string, like a separator, so that may be why it doesn't apply to it. Or it could just be something they chose to do internally due to optimizations and not trimming the right side of the value. Or just because a lot of older core functions operate based on how things are typically done IRL (ie: like when you list numbers, you don't put a space before the comma).

If my thought is right, then " 1, 2" should work.

And "1, 2 " shouldn't according to the quote since the space is after the 2 (but they may just do a general "trim()" on the value internally or something too to let that pass). You might be able to test that further with the float scanf format specifier (which uses 3 numbers.. like so "1, 2 , 3" wouldn't work but "1, 2, 3 " would if that is the case).

"1, 2 " works, "1, 2 3" works too since scanf just ignores the rest after it found 2 matches.

Your guess seems correct for the most part. That is, the quoted only actually applies to the text immediately preceding what that page describes as the "format specifier". That means the quote on http://www.cplusplus.com/ is clearly wrong. It says "the next non-whitespace character" not just format specifier.

Now I know not to trust that site.

Here is the correct reference I found,
http://en.cppreference.com/w/cpp/io/c/fscanf

All conversion specifiers other than [, c, and n consume and discard all leading whitespace characters before attempting to parse the input. These consumed characters do not count towards the specified maximum field width.

scanf does not ignore whitespace before all format specifier.

 

[mrjminer]

Yea, I figured that the description that site was off in some regard since it didn't exactly cover your scenario.

Good to see you found the exact reason