TIP: 472 Title: Add Support for 0d Radix Prefix to Integer Literals Version: $Revision: 1.8 $ Author: Venkat Iyer Author: Brian Griffin State: Accepted Type: Project Vote: Done Created: 25-May-2017 Post-History: Tcl-Version: 8.7 ~ Abstract This TIP proposes adding support for a '''0d''' decimal radix prefix to complement the existing '''0x''' hexidecimal, '''0o''' octal and '''0b''' binary radix prefixes. ~ Rationale Verilog (and other Hardware Description Languages) always (or at least since the 1995 LRM) had a way to specify a decimal number explicitly. Verilog uses ''''d343534''' to mean decimal, VHDL actually allows any radix from 2 to 16 using syntax, so you could explicitly force a decimal interpretation using '''10#343534#'''. Tcl now allows '''0b''' for binary in '''expr''' and '''format''', which is similar to ''''b''' in Verilog. And of course the '''0x''' prefix has always been around. Another use case would be to prevent false parsing of leading zeroes in '''clock format'''s as octal, without having to go through a '''scan'''. But a more elegant reason is that it makes the radix definition consistent, so 1. all valid input radixes have a consistent unambiguous input literal format, and 2. the '''d''' in '''format %d''' finally finds its complement in '''scan'''. ~ Specification Extend the '''TclParseNumber''' function to recognize the prefixes '''0d''' and '''0D''' as decimal integers. It will have the same semantics as '''0x''', but base 10 instead of base 16. Also extend format command '#' flag to produce the appropriate "0d" for the "%#d" conversion. ~ Examples It's an integer: | % expr {0d12 + 0d15} | 27 | % format "%#x" 0d1024 | 0x400 | % format "%#d" 128 | 0d128 Errors same as other radix prefixes: | % expr { 0d317g } | invalid bareword "0d317g" | in expression " 0d317g "; | should be "$0d317g" or "{0d317g}" or "0d317g(...)" or ... | % expr { 0x1.53 } | missing operator at _@_ | in expression " 0x1_@_.53 " | % expr {0d7.23} | missing operator at _@_ | in expression "0d7_@_.23" ~ Compatibility Currently, literals beginning with '''0d''' and parsed as a number will produce an error. Any code expecting such an error would fail to produce an error an thus have a change in behavior. I would expect this situation to be uncommon. ~ Implementation An implementation can be found the fossil on the "bsg-0d-radix-prefix" branch, including %#d conversion support. ~ Copyright This document has been placed in the public domain.