361274 - embedded nulls in Javascript object property names not allowed?

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[Jason Sachs]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1) Gecko/20061010 Firefox/2.0

As I mentioned in the newsgroups:

http://groups.google.com/group/mozilla.dev.tech.js-engine/browse_thread/thread/f7cd724599385b28/3b2fb62f4c332d8d

<script language=javascript>
x='123'+'\0'+'456';
y='123'+'\0'+'789';
a={};
a[x]=1;
a[y]=2;
s='(x==y): '+(x==y)+'\na[x]: '+a[x]+'\na[y]: '+a[y]+'\na["123"]:
'+a["123"];
alert(s);
</script>

On Mozilla (and in JSDB which also uses Spidermonkey) this prints
(x==y): false
a[x]: 2
a[y]: 2
a["123"]: 2

It appears object indices use a different equality metric than
Javascript's string equality operator "==", namely that Javascript
strings have an overall length and don't just stop at an embedded null
character, whereas object indices seem to stop at an embedded null.

Is this behavior documented somewhere (and is it intentional or a bug)?

I realize this is a kind of obscure case, but it is possible to use strings with embedded nulls... e.g. perhaps if I am reading in binary data from a file and using that as a key into a lookup table.

Reproducible: Always

Comment 1

[Brendan Eich [:brendan]]

Attachment: fix

Old bug, biting only property identifiers that start with a (positive or negative) number that could fit in a tagged integer.  Thanks for finding it.

/be

Comment 2

[Brendan Eich [:brendan]]

Fixed on trunk:

Checking in jsobj.c;
/cvsroot/mozilla/js/src/jsobj.c,v  <--  jsobj.c
new revision: 3.302; previous revision: 3.301
done

This is actually a fairly bad standards conformance bug, in my view.  You can't count on mapping arbitrary strings to values using objects, while JS back to Netscape 2 (JavaScript 1.0) and ECMA say you can do that, and you should be able to, respectively.  IIRC this broke in the Mozilla world; not sure about Netscape 4, but IE and others get it right AFAIK.

/be

Comment 3

[Bob Clary [:bc] (inactive)]

Checking in regress-361274.js;
/cvsroot/mozilla/js/tests/ecma_3/Object/regress-361274.js,v  <--  regress-361274.js
initial revision: 1.1
done

Comment 4

[Jay Patel [:jay]]

Brendan: Is the patch in this bug good for both branches?  Please submit separate patches if needed and ask for checkin approval...I can then + them for landing.  Thanks!

Comment 5

[Brendan Eich [:brendan]]

Comment on attachment 246056 [details] [diff] [review]
fix

This applies cleanly to the 1.8 branch, as expected. New patch for 1.8.0 next.

/be

Comment 6

[Brendan Eich [:brendan]]

Attachment: fix merged to 1.8.0 branch

Comment 7

[Jay Patel [:jay]]

Comment on attachment 246056 [details] [diff] [review]
fix

Approved for 1.8.1 branch, a=jay for drivers.

Comment 8

[Jay Patel [:jay]]

Comment on attachment 246190 [details] [diff] [review]
fix merged to 1.8.0 branch

Approved for 1.8.0 branch, a=jay for drivers.

Comment 9

[Brendan Eich [:brendan]]

Checking in jsobj.c;
/cvsroot/mozilla/js/src/jsobj.c,v  <--  jsobj.c
new revision: 3.208.2.40; previous revision: 3.208.2.39
done

Checking in jsobj.c;
/cvsroot/mozilla/js/src/jsobj.c,v  <--  jsobj.c
new revision: 3.208.2.12.2.17; previous revision: 3.208.2.12.2.16
done

/be

Comment 10

[Bob Clary [:bc] (inactive)]

verified fixed 20061122 1.8.1.1 windows/linux/mac*, 1.9 windows/linux

Comment 11

[Bob Clary [:bc] (inactive)]

oops, forgot to say verified fixed 20061122 1.8.0.9 windows/linux/mac*