It now passes all of the tests in 15.1.2.2-1 (except that parseInt
still has the .length property, which is a different bug) - so I'll
close the bug.
Still possibly at issue is whether we conform to ECMA language about
decimal numbers that are too large to fit in a double. I treat
decimal digits after the 20th as zero, but there could be some
floating-point rounding wackiness going on. In particular - are we
doing the right thing for numbers that are powers of 2, but larger
than 2^54, that are representable in a double?
git-svn-id: svn://10.0.0.236/trunk@2143 18797224-902f-48f8-a5cc-f745e15eee43
Array.prototype.sort(comparefn) was casting the result of the compare
to an int, which lost when the compare function returned (ecma-valid)
strange double values. These now get clamped to -1, 0, 1.
git-svn-id: svn://10.0.0.236/trunk@1570 18797224-902f-48f8-a5cc-f745e15eee43
Added support in the javascript shell for the #! unix script hack; if
the first line read by the shell (from a file, not interactive) starts
with #, the line is treated as a comment.
This should make
#!/usr/bin/js work...
git-svn-id: svn://10.0.0.236/trunk@1376 18797224-902f-48f8-a5cc-f745e15eee43
character strings; added a js_DeflateString call. Thanks to gcc 2.8.1
for catching this - it complained about "char format, different type
arg (arg 4)" - which means that it looked in the (printf-style) format
string and checked type against it. Wow.
git-svn-id: svn://10.0.0.236/trunk@963 18797224-902f-48f8-a5cc-f745e15eee43
changed jsdate.c to detect failure and default to using toString in
place of toLocaleString whenever FormatTime fails.
git-svn-id: svn://10.0.0.236/trunk@895 18797224-902f-48f8-a5cc-f745e15eee43
a localized string from the os for toLocaleString. The time struct
used to interface to the os time-formatting functions only takes a
16-bit year, so we map to an equivalent year (for getting the timezone
string) or clamp for years outside that range.
git-svn-id: svn://10.0.0.236/trunk@886 18797224-902f-48f8-a5cc-f745e15eee43
reserved words, and changed the versioning check that previously
applied to 'export' to accept any 'ecma' version... which means that
export becomes a keyword for the default version. Does this mean
we'll need to unreserve all the java keywords? Not sure we want to do
that...
git-svn-id: svn://10.0.0.236/trunk@881 18797224-902f-48f8-a5cc-f745e15eee43
identifier; it was only printing the first character of the
identifier, because it expected 8-bit chars, and was being called with
a 16-bit representation of the offending keyword.
git-svn-id: svn://10.0.0.236/trunk@880 18797224-902f-48f8-a5cc-f745e15eee43
functions created with new Function as "function anonymous (...)".
Now only version 1.2 decompiles to the source for an anonymous
function.
git-svn-id: svn://10.0.0.236/trunk@643 18797224-902f-48f8-a5cc-f745e15eee43
A. Hodgkinson <ahodgkin@acorn.co.uk> for finding this (and to chouck
for checking it in to js/ref/jsapi.c.)
git-svn-id: svn://10.0.0.236/trunk@639 18797224-902f-48f8-a5cc-f745e15eee43
it, even when the only assignments have been to local JS variables.
Thanks to ahodgkin@acorn.co.uk for noticing.
git-svn-id: svn://10.0.0.236/trunk@606 18797224-902f-48f8-a5cc-f745e15eee43
Initial check-in:
JSRef is migrating from /m/src JSFUN13_BRANCH to trunk /m/pub repository
git-svn-id: svn://10.0.0.236/trunk@583 18797224-902f-48f8-a5cc-f745e15eee43
Initial check-in to mozilla tree: JSRef development is migrating from
JSFUN13_BRANCH of /m/src repository to /m/pub
git-svn-id: svn://10.0.0.236/trunk@582 18797224-902f-48f8-a5cc-f745e15eee43
few constants, added -ldl for Linux. Tested on Irix 6.3, SunOs 5.6,
Linux 2.031.
git-svn-id: svn://10.0.0.236/trunk@538 18797224-902f-48f8-a5cc-f745e15eee43
