For cases where large non-fp numeric literals might end up triggering
coversion or rounding errors when stored as doubles when lexing.
This is a corner case, but it does trigger a case or two in the ECMA5
test suite (test262).
Change-Id: Ie6d355e28379aba9a339c4e345b5d2a0c32d5fdd
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
int Lexer::scanNumber(QChar ch)
{
if (ch != QLatin1Char('0')) {
- double integer = ch.unicode() - '0';
+ quint64 integer = ch.unicode() - '0';
QChar n = _char;
const QChar *code = _codePtr;
property variant n5: 3e-12
property variant n6: 3e+12
property variant n7: 0.1e9
+ property variant n8: 1152921504606846976
property variant c1: "\b" // special characters
property variant c2: "\f"
QTest::newRow("fp3") << "n5" << QVariant(3e-12);
QTest::newRow("fp4") << "n6" << QVariant(3e+12);
QTest::newRow("fp5") << "n7" << QVariant(0.1e9);
+ QTest::newRow("large-int") << "n8" << QVariant((double) 1152921504606846976);
QTest::newRow("special1") << "c1" << QVariant(QString("\b"));
QTest::newRow("special2") << "c2" << QVariant(QString("\f"));