P% scan 0x11 %x
-  17
P% scan 0b11 %b
-  3
P% scan 0d11 %d
-  0
P% scan 0o11 %o
-  0

expected 11 for the decimal scan and 9 for the octal one.

The man page doesn't make it obvious to me that scan 0x11 should return 17 rather than 0 - but it seems this has worked for a while - so my guess is that decimal and octal should be updated to match the binary and hex behaviour.

Works as intended.

The scan man page states that scan functions "...  in a fashion similar to the ANSI C sscanf procedure ...", with a few explicitly identified exceptions. 
With this in mind, I conclude that the scan is functioning as designed, matching C's sscanf behavior as shown in these results:


```
usage: ./cscan <string-value> <format-string> <value-type:(i|b|d|f|c)>
Uninitialized variables have value of -777, -7.77, or "BAAD"

sscanf("0o110", "%o%s", &i, &remainder) -> returned 2, results i=0 remainder="o110"
 scan  "0o110"  "%o%s"  i    remainder  -> returned 2, results i=0 remainder="o110"
sscanf("0d110", "%d%s", &i, &remainder) -> returned 2, results i=0 remainder="d110"
 scan  "0d110"  "%d%s"  i    remainder  -> returned 2, results i=0 remainder="d110"
sscanf("0x110", "%x%s", &i, &remainder) -> returned 1, results i=272 remainder="BAAD"
 scan  "0x110"  "%x%s"  i    remainder  -> returned 1, results i=272 remainder="BAAD"
sscanf("0b110", "%b%s", &i, &remainder) -> returned 0, results i=-777 remainder="BAAD"
 scan  "0b110"  "%b%s"  i    remainder  -> returned 1, results i=6 remainder="BAAD"
sscanf("true", "%b%s", &i, &remainder) -> returned 0, results i=-777 remainder="BAAD"
 scan  "true"  "%b%s"  i    remainder  -> returned 0, results i=-777 remainder="BAAD"
sscanf("0", "%b%s", &i, &remainder) -> returned 0, results i=-777 remainder="BAAD"
 scan  "0"  "%b%s"  i    remainder  -> returned 1, results i=0 remainder="BAAD"
sscanf("0110", "%o%s", &i, &remainder) -> returned 1, results i=72 remainder="BAAD"
 scan  "0110"  "%o%s"  i    remainder  -> returned 1, results i=72 remainder="BAAD"
sscanf("110", "%o%s", &i, &remainder) -> returned 1, results i=72 remainder="BAAD"
 scan  "110"  "%o%s"  i    remainder  -> returned 1, results i=72 remainder="BAAD"
sscanf("110", "%i%s", &i, &remainder) -> returned 1, results i=110 remainder="BAAD"
 scan  "110"  "%i%s"  i    remainder  -> returned 1, results i=110 remainder="BAAD"
sscanf("110.3ms", "%lg%s", &d, &remainder) -> returned 2, results d=110.300000 remainder="ms"
 scan  "110.3ms"  "%lg%s"  d    remainder  -> returned 2, results d=110.3 remainder="ms"
sscanf("0d10", "%x%s", &i, &remainder) -> returned 1, results i=3344 remainder="BAAD"
 scan  "0d10"  "%x%s"  i    remainder  -> returned 1, results i=3344 remainder="BAAD"
sscanf("0b10", "%x%s", &i, &remainder) -> returned 1, results i=2832 remainder="BAAD"
 scan  "0b10"  "%x%s"  i    remainder  -> returned 1, results i=2832 remainder="BAAD"
sscanf("0x10", "%x%s", &i, &remainder) -> returned 1, results i=16 remainder="BAAD"
 scan  "0x10"  "%x%s"  i    remainder  -> returned 1, results i=16 remainder="BAAD"

```

See the attached files to reproduce these results.

I am closing this as "wont fixed", works as intended.

With the current state of trunk, Tcl scan matches C's sscanf() behavior, AFAICT.

So it depends on what specification the Tcl implementation is intended to address: C compatible string input? Or, Tcl compatible string input. Given Tcl's "everything is a string" and the plethora of ways for Tcl to process a number, I think C compatibility may be more important wrt scan, IMHO.

Thoughts?

It could also be considered as a bug in %o/%d. Since %x recognises the "0x" prefix and %b recognises the "0b" prefix, I would expect %d to recognize the "0d" prefix and %o the "0o" prefix.

Indeed, it's not consistant now. How about:

scan should consume only the characters in the alphabet of a given specifier, and its prefix (depending on the given radix).

So if %x is given, "0x" is the only prefix recognised. When %o is given "0o" is the only radix recognised.

This looks like a bug in %x and %b specifiers; [scan] should consume only the characters in the alphabet of a given specifier.

% scan 0o110 %o%s
0 o110
% scan 0d110 %d%s
0 d110
% scan 0x110 %x%s
272 {}
% scan 0b110 %b%s
6 {}

[regexp] already rejects hexadecimal qualifiers

% regexp {^[[:xdigit:]]*$} 0xabc35d
0
% regexp {^[[:xdigit:]]*$} 0abc35d
1

Also, since both "b" and  "d" are members of the hexadecimal alphabet, [scan] will behave inconsistently with these numbers:

% scan 0d10 %x
3344
% scan 0b10 %x
2832
% scan 0x10 %x
16

IMO "scan" should not be using an interpretation of the string (i.e. internal rep). 
It should only be using the string value. 
It also should be strict with the format type, 
so %d should accept only { 0 1 2 3 4 5 6 7 8 9 + - }. 
Nothing else.
Only if the # flag is used in the %d format specifier should the 0d prefix be accepted.

The C standard library definition should be used here to inform the implementation of [scan].

And now I don't see the problem..  you scan as hex if you want to get hex - but should be able to scan 0b11 or 0d11 as binary or decimal.
I'll be quiet now and let someone else weigh in on all this.

ok.. thinking on this further
0b and 0d are valid hex.. so I see the problem!

I guess this can't be made to work.. sorry for the noise!

Also - with tip 114 for Tcl9
Is the behaviour

% scan 011 %i
9

The desired outcome still?
My assumption is that this should be updated for Tcl9 and %i should heed the radix specifiers and not automatically treat leading zeros as octal.

As it stands scan ... %i only seems to recognize 0x

Can this all be made more coherent for 9?