367199 - check for object-to-object conversion invoking valueOf in violation of ECMA-262 Ed.3

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Brian Crowder]

See comments 0 and 1 in bug 314874

Per discussion with Brendan on IRC, it may not (now) be the right thing to do to adhere to the spec in this case, and this point.  Nevertheless, here's the bug for posterity, if nothing else.

Comment 1

[Brendan Eich [:brendan]]

Could you list the places in the tree that implement JSObjectOps.defaultValue or JSClass.convert or valueOf and handle the object to object case?

/be

Comment 2

[Brian Crowder]

jsxml.c:5282 (or thereabouts) uses ToXMLList to build the new object, if the original object wasn't JSXML_CLASS_LIST

jsarray.c:469 (or thereabouts) uses js_TryValueOf

I think that's it for stuff inside SpiderMonkey,
Reviewing the rest of the mozilla tree is more interesting.  :)

Comment 3

[Brian Crowder]

Dropping this low-priority bug from my list.

Comment 4

[Daira Hopwood]

What precisely is "object-to-object conversion", and when does it happen?

For the design of secure JavaScript subsets (Caja, ADsafe, Jacaranda, FBJS), it's essential to know *all* cases in which implementations perform implicit conversions.

Comment 5

[Daira Hopwood]

(In reply to comment #4)
> What precisely is "object-to-object conversion", and when does it happen?
> 
> For the design of secure JavaScript subsets (Caja, ADsafe, Jacaranda, FBJS),
> it's essential to know *all* cases in which implementations perform implicit
> conversions.

I still need the answer to the above question.

A list of C source files and functions doesn't really help. When is js_TryValueOf called in terms of JavaScript code, for example?

Comment 6

[Brendan Eich [:brendan]]

(In reply to comment #5)
> (In reply to comment #4)
> > What precisely is "object-to-object conversion", and when does it happen?

There is no object-to-object conversion specified in ECMA-262. The only paths in SpiderMonkey involve native and host objects. The natives in SpiderMonkey that might js_TryValueOf are covered in ECMA-262 and ECMA-357. Host objects are a zoo as you know.

> > For the design of secure JavaScript subsets (Caja, ADsafe, Jacaranda, FBJS),
> > it's essential to know *all* cases in which implementations perform implicit
> > conversions.
> 
> I still need the answer to the above question.

Do try to give as well as take.

> A list of C source files and functions doesn't really help.

If that's in reference to my comment 1 request to crowder or his comment 2 reply, the list certainly *does* help us (whether it helps you or not) make progress on this bug (and fixing this bug, from your own comments, would help you achieve your goals).

Comments should speak to the general audience and promote the common good without narrow special-pleading or demands for someone else to provide free (and possibly not-reliably-tasty :-/) lunches.

> When is
> js_TryValueOf called in terms of JavaScript code, for example?

If you're developing a secure subset but unwilling to dive into open source to be sure of answers others might give you, I'm not sure your subset is "secure". You could always blame those you were trusting if someone either made a mistake or lied, but what good is blamecasting?

There aren't that many people around who (a) care about the "secure" subsets you mentioned and (b) might be able to help do the necessary analysis through code reading and black-box testing. You are one such person, and you are here commenting. So help yourself and you'll be much more likely to be given help, along with gaining ability to verify claims that you'd otherwise have to trust and parrot.

/be

Comment 7

[Brendan Eich [:brendan]]

From private correspondence, I learned this bug's summary may not be clear enough. It's not about setters coercing results of assignment, or even coercing stored property values (overriding [[Put]]; see bug 465199). It is only about whether any native object implements valueOf to return a different object from itself, for any value of the "Hint" parameter.

/be

Comment 8

[Daira Hopwood]

(In reply to comment #7)
> [This bug] is only about whether any native object implements valueOf to
> return a different object from itself, for any value of the "Hint" parameter.

Thankyou. Let's make this more precise:

 - the potential bug would be that, for some native object type, its
   [[DefaultValue]] internal method is overridden to do something
   different from the algorithm in ECMA-262 section 8.6.2.6, or
   its implementations of valueOf and/or toString do not conform to
   the appropriate spec in ECMA-262 section 15.

 - it has not been checked whether this bug actually exists in
   SpiderMonkey trunk.

I'm still concerned that this is not a complete answer to my question, though. The bug description (still after your clarification) seems to suggest that there is some extension to the [[DefaultValue]] mechanism that results in "object to object conversions". But [[DefaultValue]] must always return a non-object, since ToPrimitive assumes that it does.

Also, is JSClass.convert simply part of SpiderMonkey's implementation of [[DefaultValue]], or is it something else?

Comment 9

[Brendan Eich [:brendan]]

SpiderMonkey's internal APIs do not match ECMA-262's meta-methods.

Taking to settle this -- it's silly to have it linger in the [e-mail] pool but collect comments. It needs an owner, and although I'm not exactly flush with free time, it looks like I'm "it".

I will give code reading exercises to interested helpers so we can confirm the purported fix.

/be

Comment 10

[Brendan Eich [:brendan]]

I reviewed calls and definitions of js_ValueTo*Object, *_[dD]efaultValue, and *_convert. Apart from E4X (jsxml.cpp) following ECMA-357, the only object->object conversions possible lie in liveconnect (which is going away).

/be