Skip to content

fix: lex .5 and 5. as numbers, and not 5E and 5e+ - #59

Merged
borgar merged 2 commits into
borgar:masterfrom
gthb:fix-leading-dot-number
Aug 27, 2026
Merged

fix: lex .5 and 5. as numbers, and not 5E and 5e+#59
borgar merged 2 commits into
borgar:masterfrom
gthb:fix-leading-dot-number

Conversation

@gthb

@gthb gthb commented Aug 26, 2026

Copy link
Copy Markdown
Contributor

Fix three misreadings of number forms, inconsistent with Excel:

  • A numeric literal with no integer part (.95, -.5) was lexed as unknown followed by an integer number. The . can now start a number. A lone . without a digit on at least one side stays unknown.

  • A numeric literal with a dot but no fractional part (1., 1.*2, 1.E5) was lexed as a number only at the end of the input (accidentally, because of a NaN gotcha, see below) and unknown elsewhere. Now a number everywhere.

  • An unfinished exponent at the end of the input (1E, 1.5e+) was lexed as a number, because of a NaN gotcha in advDigits.

The NaN gotcha in advDigits: it used a do-while loop, so didn't check string length before the first iteration. So if pos was after the end of the string, str.charCodeAt returned NaN. The result of c < 48 || c > 57 (false for NaN) was then misunderstood as meaning that c was in the 0-9 range.

gthb added 2 commits August 26, 2026 11:09
Fix three misreadings of number forms, inconsistent with Excel:

- A numeric literal with no integer part (`.95`, `-.5`) was lexed as `unknown`
  followed by an integer number. The `.` can now start a number. A lone `.`
  without a digit on at least one side stays `unknown`.

- A numeric literal with a dot but no fractional part (`1.`, `1.*2`, `1.E5`)
  was lexed as a number only at the end of the input (accidentally, because of
  a NaN gotcha, see below) and `unknown` elsewhere. Now a number everywhere.

- An unfinished exponent at the end of the input (`1E`, `1.5e+`) was lexed as a
  number, because of a NaN gotcha in `advDigits`.

The NaN gotcha in `advDigits`: it used a do-while loop, so didn't check string
length before the first iteration. So if `pos` was after the end of the string,
`str.charCodeAt` returned NaN. The result of `c < 48 || c > 57` (false for NaN)
was then misunderstood as meaning that `c` was in the 0-9 range.
The tail guard that keeps a number from swallowing a sheet or range operator applies to the new form; pin it, per review.
@borgar
borgar merged commit e381d20 into borgar:master Aug 27, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants