Pop Quiz

For a while, perl had a bug whereby floating point numbers would be interpreted slightly differently depending on where they were used -- it hit very rarely, and only effected the last digit. The problem? Two different functions were being used, one for compile-time constants, one for arithemetic on strings holding floating-point numbers, that did the conversion ever-so-slightly differently. Perl has a much looser compiletime/runtime dichtomy then many languages, and will happily give you warnings at runtime when it feels the need, so that's not an issue there, but the lesson is still important -- stuble differences in behavior aren't generally a good thing, when your users expect two things to work the same way, and if you implement something twice, you'll end up with subtle differences in behavior.

Interesting. That is kind of weird to use a runtime function to do the conversion.

We check for bad octals in the scanner so the warning has already gone out before anyone gets their hands on the token.

Right -- James has hit the nail on the head. There's only one place in the JScript code that converts strings to numbers, and that's the same code that is used in parseInt/parseFloat/etc, so that they remain consistent with each other. (Though there are in fact some oddities, which might be a good subject for a future entry.)

Your design is better -- the warning should have gone into the scanner, not into the portion of the parser which turns numeric literal tokens into expression nodes in the abstract syntax tree.

Eric - talk about response times... 11:43 AM Nicholas Allen reports a possible bug. 12:01 PM Eric Lippert finds the internal source code, determines the problem, adds a warning in the code, and writes a response.

Indeed.

I'm not actually going to FIX it, mind you. I don't own that code anymore. Next time I see the owner, I'll mention it to him, but this is a pretty low-priority fix.