in both directions.
72552: Remedy overzealous CHECK_REQUEST placement in jsapi.c, to produce a
minimal-but-complete set of engine entry points that require a Request
for safe execution.
r=brendan, sr=jband, assist=scc,pinkerton
where any occurrence of arguments.length or arguments[0], e.g., would be
"optimized" to use those bytecodes. This is just wrong if the occurrence
is an operand of delete, ++, --, or the left-hand-side of an assignment
operator!
- [jsfun.c, jsinterp.c] args_getProperty etc. must use JS_GetInstancePrivate,
not JS_GetPrivate, as the arguments object is exposed, and can be made a
prototype of other objects that do not have private data, or private data
that's a JSStackFrame*. Same goes for fun_getProperty, js_GetArgument, etc.
- [jsfun.c, jsobj.c, jsstr.c] No need to specialize fun_delProperty and
str_delProperty to help convince users and ECMA conformance tests that
fun.length and str.length are direct properties of instances, instead of
being delegated to Function.prototype.length and String.prototype.length.
This special case is done universally in js_DeleteProperty for all SHARED
and PERMANENT proto-properties.
- [jshash.c] Sneaking this followup-fix for bug 69271 in: use JS_HASH_BITS
rather than hardcoded 32.
- [jsobj.c, jsscope.[ch]] Fix misnamed js_HashValue (it takes a jsid, so it
is now js_HashId).
- [jsscript.c] script_compile needs to call JS_InstanceOf, to ensure that obj
is a Script object.
- Don't ape java.lang.String's bogo-sampling hash function for "long" (>=16
char) strings.
- Theory and practice comment in jsdhash.h helps analyze when to use double
hashing (most of the time) vs. when to use chaining.
- Subroutine ChangeTable from JS_DHashTableOperate so it can be called from
JS_DHashTableEnumerate, if the latter finds that enough entries have been
removed to be worth a shrink or compress cycle.
- teach nsGenericFactory about nsIClassInfo, and nsIClassInfo.idl to the
builds
- add a heaping serving of macro love for classes that want to support it
- convert many modules to use nsGenericModule the new way
- handful of warning and modeline fixes
- nsSample and some XPConnect test classes now have nsIClassInfo support for
testing
r=pchwartau, sr=brendan
Just add an _IS_LITTLE_ENDIAN for XP_OS2 for now. Eventually, we need to figure
out how to get jstypes.h included in here, since it already has a LITTLE_ENDIAN define.
r=pchwartau, sr=brendan
Rework makefile.win and js.mak for the eventual ability to include jstypes.h in fdlibm.h
Not turned on yet because I can't get it working right on Linux
- Fix bug where script jssrcnote vector terminator was not XDRed.
- Ensure that memory is cleared by serializing zero padding bytes as needed
under JS_XDRBytes and JS_XDRString.
- Fix JS_XDRValue to handle undefined and null JS types properly (bug 31003).
Also make it cast from jsint to uint32 and back carefully, so as to work
with negative numbers even on targets where jsval is a signed 64 bit type.
- Add JS_XDRScript public API.
- Optimize the per-JSXDRState class registry so it uses a JSDHashTable upon
searching for a class-id by name in an overpopulated (for linear search)
registry table.
- Clean up API nits such as JS_XDRNewBase => JS_XDRInitBase, with parameter
list rotation to put cx last (JS_XDRInitBase is an infallible init helper,
not an error-reporting, cx-comes-first, API entry point).
- Fix some XXX comments, unneeded masks, other nits.
- Make sure all JS XDR API functions start with JS_XDR.
* fixed ImporterTopLevel constructor - it now calls
cx.initStandardObjects before defining any functions. The old
constructor is still around for backwards compatibility.
- Fix scope chain for nested functions at top-level (JSOP_DEFFUN), in a part of another statement (JSOP_CLOSURE), and unnamed in an expression (JSOP_ANONFUNOBJ) to match ECMA-262 13.2. My bad: fp->varobj was used up till now, instead of fp->scopeChain; we still *bind* the name of a statement-level (top or not) nested function in fp->varobj. This fixes bug 69559. (r=rogerl, sr=jband)
- Add an Intern command to the shell, for GC vs. intern'ed atom testing.
Rhino Context.setTargetClassFileName() null pointer exception
Date:
Tue, 20 Feb 2001 15:28:20 -0800
From:
"Ryan Manwiller" <rdm@europa.com>
Organization:
Another Netscape Collabra Server User
Newsgroups:
netscape.public.mozilla.jseng
I'm setting the file name to compile to a file. However, on subsequent
compiles, I don't want to compile to a file, so I tried
setTargetClassFileName(null). This causes a NullPpinterException in
OptClassNameHelper.setTargetClassFileName(OptClassNameHelper.java:76)
It seems that Context.setTargetClassFileName() should check for null.
Thanks
shaver%mozilla.org
waterson%netscape.com
pschwartau%netscape.com
mkaply%us.ibm.com
disttsc%bart.nl
dmose%netscape.com
brendan%mozilla.org
nboyd%atg.com
jband%netscape.com
beard%netscape.com
rginda%netscape.com
Peter.VanderBeken%pandora.be
dprice%netscape.com
rogerl%netscape.com
matthias%sorted.org