diff options
author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-28 14:29:10 +0000 |
---|---|---|
committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-28 14:29:10 +0000 |
commit | 2aa4a82499d4becd2284cdb482213d541b8804dd (patch) | |
tree | b80bf8bf13c3766139fbacc530efd0dd9d54394c /js/src/jit-test/tests/basic/bug653153.js | |
parent | Initial commit. (diff) | |
download | firefox-upstream.tar.xz firefox-upstream.zip |
Adding upstream version 86.0.1.upstream/86.0.1upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'js/src/jit-test/tests/basic/bug653153.js')
-rw-r--r-- | js/src/jit-test/tests/basic/bug653153.js | 76 |
1 files changed, 76 insertions, 0 deletions
diff --git a/js/src/jit-test/tests/basic/bug653153.js b/js/src/jit-test/tests/basic/bug653153.js new file mode 100644 index 0000000000..c06e3b82b8 --- /dev/null +++ b/js/src/jit-test/tests/basic/bug653153.js @@ -0,0 +1,76 @@ +// ES5 15.1.2.2 step 1 + +/* + * Boundary testing for super-large positive numbers between non-exponential + * and in-exponential-form. + * + * NB: While 1e21 is exactly representable as an IEEE754 double-precision + * number, its nearest neighboring representable values are a good distance + * away, 65536 to be precise. + */ + +// This is the boundary in theory. +assertEq(parseInt(1e21), 1); + +// This is the boundary in practice. +assertEq(parseInt(1e21 - 65537) > 1e20, true); +assertEq(parseInt(1e21 - 65536), 1); +assertEq(parseInt(1e21 + 65536), 1); + +// Check that we understand floating point accuracy near the boundary +assertEq(1e21 - 65537 !== 1e21 - 65536, true); +assertEq(1e21 - 65536, 1e21); +assertEq(1e21 + 65535, 1e21); +assertEq(1e21 + 65536, 1e21); + +// ES5 leaves exact precision in ToString(bigMagNum) undefined, which +// might make this value inconsistent across implementations (maybe, +// nobody's done the math here). Regardless, it's definitely a number +// very close to 1, and not a large-magnitude positive number. +assertEq(1e21 + 65537 !== 1e21, true); +assertEq(parseInt(1e21 + 65537) < 1.001, true); + + +/* + * Now do the same tests for super-large negative numbers crossing the + * opposite boundary. + */ + +// This is the boundary in theory. +assertEq(parseInt(-1e21), -1); + +// This is the boundary in practice. +assertEq(parseInt(-1e21 + 65537) < -1e20, true); +assertEq(parseInt(-1e21 + 65536), -1); +assertEq(parseInt(-1e21 - 65536), -1); + +// Check that we understand floating point accuracy near the boundary +assertEq(-1e21 + 65537 !== -1e21 + 65536, true); +assertEq(-1e21 + 65536, -1e21); +assertEq(-1e21 - 65535, -1e21); +assertEq(-1e21 - 65536, -1e21); + +// ES5 leaves exact precision in ToString(bigMagNum) undefined, which +// might make this value inconsistent across implementations (maybe, +// nobody's done the math here). Regardless, it's definitely a number +// very close to -1, and not a large-magnitude negative number. +assertEq(-1e21 - 65537 !== 1e21, true); +assertEq(parseInt(-1e21 - 65537) > -1.001, true); + + +/* Check values around the boundary. */ +arr = [1e0, 5e1, 9e19, 0.1e20, 1.3e20, 1e20, 9e20, 9.99e20, 0.1e21, + 1e21, 1.0e21, 2e21, 2e20, 2.1e22, 9e21, 0.1e22, 1e22, 3e46, 3e23, 3e100, 3.4e200, 7e1000, + 1e21, 1e21+65537, 1e21+65536, 1e21-65536, 1e21-65537]; + +/* Check across a range of values in case we missed anything. */ +for (var i = 0; i < 4000; i++) { + arr.push(1e19 + i*1e19); +} + +for (var i in arr) { + assertEq(parseInt( arr[i]), parseInt(String( arr[i]))); + assertEq(parseInt(-arr[i]), parseInt(String(-arr[i]))); +} + + |