620761 - JM: eval("NaN") ignores "var NaN"

Status: RESOLVED DUPLICATE of bug 617171

(Core :: JavaScript Engine, defect)

Description

[Jesse Ruderman]

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

Comment 1

[Andreas Gal :gal]

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

Comment 2

[Andreas Gal :gal]

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

Comment 3

[Jeff Walden [:Waldo]]

(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?

Comment 4

[David Mandelin [:dmandelin]]

(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

Comment 5

[Jeff Walden [:Waldo]]

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