and development branches, including but
not limited to:
- Preliminary exception handling per
ECMA proposal; try, multiple
catchblocks, and finally. Catchblocks
are of the form catch (v) or
catch(v:<guard>), where guard is an
optional boolean expression that is
evaluated to determine whether the
exception is to be caught by that block.
- ECMA-proposed 'in' operator; "'foo' in
o" or "4 in o" asks if o has property
foo or element 4.
- Added a new set of defines in
jsconfig.h for js 1.4
features-in-progress. (in, instanceof,
exception handling.) Default build
version is now 1.4. Fixed a few
conditional features that had become
broken.
- Progress towards porting to FreeBSD
and Alpha; casts of NaN and friends to
int are a little more localized. Not
there yet...
- New config files to compile on more
OSes; various fixes to improve
portability.
and tested in that release):
#114564: Fix JS_Enumerate to return an empty id array instead of null
#115395: Fix JS garbage collection
#115200: Security dialog no longer blows assertion
#123211: Make sure output of sort array function is -1, 0, or 1.
#116195: Fix ImportProperty(), cope with an existing local variable
of the same name as the imported property
Unbusticate JS_invoke() so that closures work again
#115384,#115395: Handle bugs in toSource that strike when
getProperty is non-idempotent. Fix crash during JavaScript
garbage collection after enumerating object properties.
#??????: mjudge - Win16 files to make ptrdiff_t be 32 bits on Win16
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.
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?
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.
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...
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.
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.
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...
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.
warren%netscape.com
beard%netscape.com
shaver%netscape.com
cls%seawood.org
brendan%netscape.com
danm%netscape.com
sudu%netscape.com
bjorn%netscape.com
mccabe%netscape.com
shaver
danm
atotic
fur
norris
mccabe
sar
scc
sfraser
matt
brendan
hshaw
donm
henrit
bjorn
ltabb