By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,607 Members | 1,931 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,607 IT Pros & Developers. It's quick & easy.

objects with string indices

P: n/a
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)?

Nov 16 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
In article <11**********************@m7g2000cwm.googlegroups. com>, Jason
S <jm*****@gmail.comwrites

<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
Nov 16 '06 #2

P: n/a
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...

Nov 16 '06 #3

P: n/a
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 :-)

Nov 16 '06 #4

P: n/a
In article <11*********************@h54g2000cwb.googlegroups. com>, VK
<sc**********@yahoo.comwrites

<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
Nov 17 '06 #5

P: n/a
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>

Nov 18 '06 #6

P: n/a
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?

Nov 21 '06 #7

P: n/a
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.
what's special about index -1 that it returns length, apparently?
Nov 21 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.