objects with string indices

[Jason S]

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

[John G Harris]

In article <1163697118.3...@m7g2000cwm.googlegroups.com>, Jason
S <jms...@gmail.com> writes

<snip>

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

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

[Jason S]

John G Harris wrote:
> I expect the unofficial answer is "why would anyone want to do that".

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...

[VK]

Jason S wrote:
> 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

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

[John G Harris]

In article <1163712419....@h54g2000cwb.googlegroups.com>, VK
<school...@yahoo.com> writes

<snip>

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

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

[VK]

John G Harris wrote:
> It didn't "keep its special value". \0 is not the null character in
> ECMAScript version 2, but it is in version 3.

15.10.2.11 DecimalEscape is the only place vaguely mentioning \0 and
NUL but right - I was deeply wrong.

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

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>

[Jason S]

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?

[Richard Cornford]

Jason S wrote:
> Apparently it was a bug.

Yes, that was a bug.

<snip.> 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

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.