208 struct JSAtomState { 229 * Literal value and type names. 230 * NB: booleanAtoms must come right before typeAtoms! 231 */ 232 JSAtom *booleanAtoms[2]; 233 JSAtom *typeAtoms[JSTYPE_LIMIT]; 376 #define INS_ATOM(atom) INS_CONSTSTR(ATOM_TO_STRING(atom)) 8298 TraceRecorder::stringify(jsval& v) 8308 } else if (JSVAL_IS_VOID(v)) { 8309 /* N.B. void is JSVAL_SPECIAL. */ 8310 return INS_ATOM(cx->runtime->atomState.booleanAtoms[2]) Is there a reason we're using booleanAtoms[2] instead of typeAtoms[0] ?

The original reason for the convolution (before the bug 552586) was to allow the original implementation of js_BooleanOrUndefinedToString: JSString* FASTCALL js_BooleanOrUndefinedToString(JSContext *cx, int32 unboxed) { JS_ASSERT(uint32(unboxed) <= 2); return ATOM_TO_STRING(cx->runtime->atomState.booleanAtoms[unboxed]); } Of course, void was specialized when TT_SPECIAL was split into TT_BOOLEAN and TT_VOID and I failed to notice the hack and instead transplanted it. This doesn't seem to be security sensitive unless you are pointing out that the compiler is technically allowed to insert arbitrary padding. I seem to recall other code depending on the exact layout of atoms.

This bug is not a bug. We have static assertions ensuring no padding. But we should use typeAtoms[0], yeah. /be