```
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
Tcl-Branch: bsg-0d-radix-prefix
```

# 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

all valid input radixes have a consistent unambiguous input literal format, and

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 [email protected]_
in expression " [email protected]_.53 "
% expr {0d7.23}
missing operator at [email protected]_
in expression "[email protected]_.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.