var NaN = 0; print(eval("NaN")); ./js NaN ./js -m 0 The first bad revision is: changeset: c47a52df435d user: Jan de Mooij date: Mon Nov 01 21:47:45 2010 +0100 summary: Bug 604864 - Optimize undefined, NaN and Infinity in methodjit. r=dmandelin

Yeah, that patch is bad. NaN is not readonly, and you can't depend on its value being what it is by default.

If you want to optimize this, we could brand the global object for those 3 properties.

(In reply to comment #1) > Yeah, that patch is bad. NaN is not readonly Um, NaN, Infinity, and undefined are all non-enumerable, non-configurable, and non-writable. |var NaN| in global code should do nothing, and |var NaN = 0| should either do nothing or throw in strict mode. Why do you thing that change to GETGNAME, which in those cases must refer to those immutable bindings, is bad?

(In reply to comment #3) > (In reply to comment #1) > > Yeah, that patch is bad. NaN is not readonly > > Um, NaN, Infinity, and undefined are all non-enumerable, non-configurable, and > non-writable. |var NaN| in global code should do nothing, and |var NaN = 0| > should either do nothing or throw in strict mode. Why do you thing that change > to GETGNAME, which in those cases must refer to those immutable bindings, is > bad? As of tip, I get different behavior from comment 0. Using: // n.js var NaN = 0; print(NaN); print(eval("NaN")) js n.js: 0 0 js -m n.js: 0 NaN

This is just bug 617171, JSOP_SETGLOBAL not checking for a writable property.