b) how is spidermonkey supposed to handle embedded nulls in property
names? I'm not sure if this is a bug. see
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/0eafd54648ebb88f/8d00f0272d85eac3
Result:
(x==y): false
a[x]: 2
a[y]: 2
a["123"]: 2
This is not a bug
'\0' represent the end of a string so when you looking for the end of your
string you do this king of code
int length(char *s)
{
int i=0;
if(s==NULL) return 0;
while(s[i]!='\0') i++;
return i;
}
In consequence if test the length of x and y it's the same because '\0'
represent the end of the string.
Le 16/11/06 22:31, « Jason S » <jms...@gmail.com> a écrit :
> _______________________________________________
> dev-tech-js-engine mailing list
> dev-tech-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
That's true in C but not true in Javascript where x and y above both
have length 7 and are not equal to each other. Apparently the concept
of equality used to compare Javascript object indices is different from
the concept of equality used to compare Javascript strings.
You said that the length is 7.
But the character '\0' represent the end of a string so the length of x and
y is not 7 but 3.
To compare you use this kind of alogorithm, don't forget spydermonkey is
write in c or Rhyno in Java.
int compare(char *s1,char *s2)
{
if(s1==NULL)
if(s2==NULL) return 0;
else return -1;
if(s2==NULL) return -1;
while((*s1==*s2)&&(*s1!='\0')&&(*s2!='\0'))
{
s1++;
s2++;
}
return(*s1-*s2);
}
In consequence x==y;
Don't forget that a string need a end flag.
Syncerely
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"];
Result:
(x==y): false
a[x]: 2
a[y]: 2
a["123"]: 2
This is not a bug
'\0' represent the end of a string so when you looking for the end of your
string you do this king of code
int length(char *s)
{
int i=0;
if(s==NULL) return 0;
while(s[i]!='\0') i++;
return i;
}
In consequence if test the length of x and y it's the same because '\0'
represent the end of the string.
Le 17/11/06 1:15, « Jason S » <jms...@gmail.com> a écrit :
maybe you should try running it instead of assuming C string rules...
here's what I get in Firefox 1.5.0.3 and Firefox 2.0 and jsdb.exe:
<script language=javascript>
x='123'+'\0'+'456';
y='123'+'\0'+'789';
s='x.length='+x.length+'\n' + 'y.length='+y.length+'\n'
+'(x==y)='+(x==y);
alert(s);
</script>
x.length=7
y.length=7
(x==y)=false
So x==y.
Le 17/11/06 14:47, « Jason S » <jms...@gmail.com> a écrit :
I believe the correct place is...
Go to: https://bugzilla.mozilla.org/enter_bug.cgi
Click on "Other Products"
Click on "Core" under "Components"
Choose "JavaScript Engine" in the "Component" listbox
>
> b) how is spidermonkey supposed to handle embedded nulls in property
> names? I'm not sure if this is a bug. see
> http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/0eafd54648ebb88f/8d00f0272d85eac3
>
I don't know the reasoning behind this offhand. I doubt this is an
undiscovered bug. I'd bet there is a rationale behind the behavior.
FWIW, I've never been able to find a decent specification of object
property names in the ECMA spec.
If none of the JS language gurus give you a good answer here then
perhaps whomever addresses Spidermonkey bug reports will have
something illuminating to say :)
John.
now this is interesting. Apparently it is a bug after all (see below,
another quick response from Brendan), and relates to numeric index
parsing. If you change "123" to "abc" it works the way I would have
expected:
<script language=javascript>
x='abc'+'\0'+'456';
y='abc'+'\0'+'789';
a={};
a[x]=1;
a[y]=2;
s='(x==y): '+(x==y)+'\na[x]: '+a[x]+'\na[y]:
'+a[y]+'\na["abc"]:'+a["abc"];
alert(s);
</script>
result on Firefox 2.0:
(x==y): false
a[x]: 1
a[y]: 2
a["abc"]: undefined
========= from bugzilla: ==============
------- Comment #1 from bre...@mozilla.org 2006-11-20 12:11 PST
-------
Created an attachment (id=246056)
-->
(https://bugzilla.mozilla.org/attachment.cgi?id=246056&action=view)
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