reporting bugs / bug in spidermonkey re: object indices and embedded nulls?

[Jason S]

a) where is the right place to report spidermonkey bugs? bugzilla
(http://bugzilla.mozilla.org) doesn't seem to have a category for
spidermonkey or Javascript.

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

[Jean-Christophe PLAGNIOL-VILLARD]

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

[Jason S]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> 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

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.

[Jean-Christophe PLAGNIOL-VILLARD]

x='123'+'\0'+'456';
y='123'+'\0'+'789';

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 :

[Jason S]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> 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.

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

[Jean-Christophe PLAGNIOL-VILLARD]

When you use your string x or y as a hash index for your array, is the
representation that is used.

So x==y.

Le 17/11/06 14:47, « Jason S » <jms...@gmail.com> a écrit :

[John Bandhauer]

Jason S wrote:
> a) where is the right place to report spidermonkey bugs? bugzilla
> (http://bugzilla.mozilla.org) doesn't seem to have a category for
> spidermonkey or Javascript.

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.

[Jason S]

thanks for the pointer on where to submit the bugreport, I had looked
but couldn't find the category.

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