stillwater-sc / universal / 32603809424

85%

master: 84%

push

github

fix(einteger): make the parse radix independent of the leading-zero count (#1381)

* fix(einteger): make the parse radix independent of the leading-zero count

parse() decided between octal and decimal in a way no caller could predict: a
single leading zero selected octal, two or more selected decimal.

    "0777"  -> 511 (octal)      "00777" -> 777 (decimal)
    "075"   ->  61 (octal)      "0075"  ->  75 (decimal)

The octal pattern required the SECOND character to be [1-7], so any string whose
second character was '0' never matched it and fell through to the decimal branch.
Zero-padding a value silently changed what it meant.

The same gap made the radix depend on the digits: a leading-zero string containing
an 8 or a 9 also fell through to decimal, so "0747" was 487 while "0749" was 749.
C rejects 08 and 0749 outright.

    octal   ^[-+]*0[1-7][0-7]*$   ->   ^[-+]*0[0-7]*$
    decimal ^[-+]*[0-9]+          ->   ^[-+]*(0|[1-9][0-9]*)$

A leading zero now commits the string to octal however many zeros there are, and
decimal no longer accepts a leading zero, so a leading-zero string with a non-octal
digit is malformed rather than quietly re-read in another radix. "0" and "00" remain
zero, which they are in any radix.

Octal support itself is unchanged and was never in question: it is a deliberate,
tested feature (elastic/einteger/conversion/string_parse.cpp has a section for it).
The issue I filed suggested dropping it on the grounds that nothing used it -- that
was wrong, and I found the test section when I went to implement it.

Callers are unaffected: the only in-tree consumer that fed parse() a possibly
zero-padded string was agreed_decimal_digits() in the elreal verification oracle,
which strips leading zeros before assign() as of #1369. A sweep of the tree finds no
other .assign() of a leading-zero decimal.

Regression coverage extends the existing octal and malformed-reject sections.
Mutation-tested: against the previous regexes nine of the new... (continued)

2 of 2 new or added lines in 1 file covered. (100.0%)

43135 of 50517 relevant lines covered (85.39%)

7188968.61 hits per line