Description
In various circumstances, the cel-go implementation ignores an unbounded number of extraneous digits in numeric literals. While this behavior is probably common to most programming languages, it might be unwise for a language designed for execution of untrusted code.
It's hard to contrive a legitimate reason to support these literals, but the spec is not explicit on whether these literals should be supported and how they should be rounded/truncated.
Unbounded number of leading zeroes for an integer:
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
// 1
Unbounded number of leading zeroes for a hexadecimal integer:
0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
// 1
Unbounded number of leading zeroes for a floating-point:
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001.0
// 1.0
Double with more precision than can be stored:
1.0000000000000001 == 1.0
// true
Double with same number of digits as above but different rounding/truncation result:
1.0000000000000002 == 1.0
// false
Unbounded number of floating-point digits:
1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001
// 1.0
Double with unbounded number of precision digits and unbounded number of exponent zeros:
1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
// 1.0
Recognizing that existing implementations may have to continue to (optionally) support the existing behavior, I would propose that the spec recommend:
- Decimal integer literals and hexadecimal integer literals must not be padded with leading zeros beyond 32 total digits.
- Double literal exponents must not be padded with leading zeros beyond 8 total digits.
- The sum of whole and fractional digits in the significand of a double literal must not be padded with any combination of leading and trailing zeros beyond 32 total digits.
Ignoring trailing zeros, the significand of a double literal must not require truncation or rounding to deserialize it as an IEEE 754 value.Thinking about this even just a little more and this seems entirely impractical. It rubs me the wrong way for4e-324 == 5e-324to be true, but maybe I just have to accept that this is ubiquitously true for IEEE 754 floating point values?