Bug 81468 – JSCallbackFunction::toStringCallback/valueOfCallback do not handle 0 return value

• Status: RESOLVED
• Resolution: FIXED
• Component: JavaScriptCore

[Gavin Barraclough]

The API specifies that convertToType may opt not to handle a conversion:
    "@result The objects's converted value, or NULL if the object was not converted."
In which case, it would propagate first up the JSClass hierarchy, calling its superclass's conversion functions, and failing that call the 

Unfortunately this behaviour was removed in bug#69677/bug#69858, and instead we now rely on the toStringCallback/valueOfCallback function introduced in bug#69156.  Even after a fix in bug#73368, these will return the result from the first convertToType they find, regardless of whether this result is null, and if no convertToType method is found in the api class hierarchy (possible if toStringCallback/valueOfCallback was accessed off the prototype chain), they will also return a null pointer.  This is unsafe.

It would be easy to make the approach based around toStringCallback/valueOfCallback continue to walk the api class hierarchy, but making the fallback to defaultValue would be problematic (since defaultValue calls toStringCallback/valueOfCallback, this would infinitely recurse).  Making the fallback work with toString/valueOf methods attached to api objects is probably not the right thing to do – instead, we should just implement the defaultValue trap for api objects.

In addition, this bug highlights that fact that JSCallbackFunction::call will allow a hard null to be returned from C to JavaScript - this is not okay.  Handle with an exception.

<rdar://problem/11034745>

[Gavin Barraclough]

oops, "and failing that call the" JSObject::defaultValue function.

[Gavin Barraclough]

Created attachment 132485 [details]
Fix

[Oliver Hunt]

Comment on attachment 132485 [details]
Fix

Can you add an additional test to testapi to verify that we don't crash on a convertToType function returning null?

[Gavin Barraclough]

Fixed in r111162