js> a = new Array()
js> a["3.00"] = "three"
three
js> a.length
4
Since "3.00" is not an array index as defined by ECMA, a.length should be 0.
git-svn-id: svn://10.0.0.236/trunk@3539 18797224-902f-48f8-a5cc-f745e15eee43
treat all the 'arguments arguments' as if they were concatenated
together as a comma-separated list, and treat the list as if it were
the arguments list in a normal function declaration. That is, allow
comments, arbitrary whitespace, etc.
Fixed by introducing a TokenStream instance in the Function contructor
code.
git-svn-id: svn://10.0.0.236/trunk@3500 18797224-902f-48f8-a5cc-f745e15eee43
now a little more explit about when it expects js strings to be
null-terminated.
git-svn-id: svn://10.0.0.236/trunk@2964 18797224-902f-48f8-a5cc-f745e15eee43
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
