# TIP 472: Add Support for 0d Radix Prefix to Integer Literals

``````Author:         Venkat Iyer <[email protected]>
Author:         Brian Griffin <[email protected]>
State:          Final
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 formats 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.