objects with string indices

I have a stumper, not sure if it belongs here or in
mozilla.dev.tech.js-engine:

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

In article <1163697118.311489.152250@m7g2000cwm.googlegroups. com>, Jason
S <jmsachs@gmail.comwrites

<snip>According to ECMA 262 you can have any characters you like in a property
name. It looks as though you've found a bug, either in a browser
implementation or in ECMA 262 (i.e they forgot to ban \0 in property
names).

I expect the unofficial answer is "why would anyone want to do that".

John
--
John Harris

John G Harris wrote:I was trying to figure out a way to do 2-D arrays, using the \0 as a
separator... though I suppose if you are doing some kind of hash lookup
based on binary data, this would be a valid method as well...

Jason S wrote:JavaScript is fully Unicode-driven, this way it is a question why would
any compliant engine make some special relationship studies between
\u0000 (NUL) and \u0030 (zero sign).

That is also a question why the silly \0 delimiter from Cx languages
would keep its special value in JavaScript - but it comes close to an
evangelism discussion :-)

In article <1163712419.099034.90540@h54g2000cwb.googlegroups. com>, VK
<schools_ring@yahoo.comwrites

<snip>It didn't "keep its special value". \0 is not the null character in
ECMAScript version 2, but it is in version 3.

It looks as though \0 was added in version 3 because so many people like
VK wanted it.

John
--
John Harris

John G Harris wrote:15.10.2.11 DecimalEscape is the only place vaguely mentioning \0 and
NUL but right - I was deeply wrong.
I wanted NUL for a language where strings are not null-terminated? No,
no, no! :-)
I played a bit with that freshly discovered (for me) NUL. While string
methods acting as they possibly(?) should if strings are not
null-terminated, overall the engine seems pretty much FOBAR (in the US
Army sense of this acronym):

<script language=javascript>
x='123'+'\0'+'456';
alert(x); // 123
alert(x.length); // 7
alert(x.charAt(6)); // 6
a={};
a[x] = 1;
for (var p in a) {
alert(''+p); // 123
alert((''+p).length); // 7
alert((''+p).charAt(6)); // 6
}

alert(x == '123');
</script>

Apparently it was a bug. If you change '123' to 'abc' it works as
expected; something to do with the index parser and the dual nature of
indices (numbers vs. strings).

I have another one that I seem to have stumbled on:
<script language=javascript>
document.open();
s = 'abcdefg';
over=2;
for (i = -over; i < s.length+over; i++)
{
document.writeln('s['+i+']='+s[i]+'<br>');
}
document.close();
</script>

I get:
s[-2]=undefined
s[-1]=7
s[0]=a
s[1]=b
s[2]=c
s[3]=d
s[4]=e
s[5]=f
s[6]=g
s[7]=undefined
s[8]=undefined

what's special about index -1 that it returns length, apparently?

Jason S wrote:Yes, that was a bug.

<snip.I have another one that I seem to have stumbled on:That is not a bug, it is an extension. There are no integer property
names defined for String object so finding an example where they exist,
and finding that a property with the name "-1" is the length of the
string, is just a feature of that specific implementation. Neither
significant nor useful (outside things like Firefox/Gecko extensions).

Richard.