Last Comment Bug 705355 - Use IDL for Components.utils.evalInSandbox
: Use IDL for Components.utils.evalInSandbox
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: XPConnect (show other bugs)
: Trunk
: All All
: -- normal (vote)
: mozilla11
Assigned To: :Ms2ger
:
Mentors:
Depends on:
Blocks: 705324
  Show dependency treegraph
 
Reported: 2011-11-25 13:11 PST by :Ms2ger
Modified: 2011-12-18 07:15 PST (History)
2 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch v1 (5.64 KB, patch)
2011-11-25 13:11 PST, :Ms2ger
no flags Details | Diff | Review
Patch v2 (5.71 KB, patch)
2011-11-26 02:43 PST, :Ms2ger
bobbyholley: review+
Details | Diff | Review
Patch v3 (5.86 KB, patch)
2011-12-06 11:50 PST, :Ms2ger
bobbyholley: review+
Details | Diff | Review

Description :Ms2ger 2011-11-25 13:11:05 PST
Created attachment 576989 [details] [diff] [review]
Patch v1
Comment 1 :Ms2ger 2011-11-26 02:43:06 PST
Created attachment 577047 [details] [diff] [review]
Patch v2

Turns out that jsVersionStr or filenameStr being null isn't a failure case:
<https://tbpl.mozilla.org/?tree=Try&rev=cb53dfe085f5>
Comment 2 Bobby Holley (PTO through June 13) 2011-12-01 18:22:14 PST
Comment on attachment 577047 [details] [diff] [review]
Patch v2

The aFoo names needs to be removed here as well.


>+    JSString *jsVersionStr = JS_ValueToString(aCx, aVersion);
>+    JSString *filenameStr = JS_ValueToString(aCx, aFilename);
>+    PRInt32 lineNo = aLineNo;

This relies on a whole host of lucky magic that is not at all explicit. In particular, it requires that XPConnect converts |[optional] in jsval| parameters to JSVAL_VOID, which is subsequently converted by JS_ValueToString() to null. It also relies on |[optional] in unsigned| being converted to JSVAL_NULL, and that ending up as zero in JS_ValueToECMAInt32 (in XPCConvert::JSData2Native).

IMO, the values of optional parameters should be consider undefined if not given, and [optional_argc] should always be used. Can we use it here?

r- until we get that figured out.
Comment 3 :Ms2ger 2011-12-02 07:28:16 PST
I disagree. We rely on the default value of optional parameters pretty much everywhere we use optional parameters. I don't see how adding more complexity here is useful.
Comment 4 Bobby Holley (PTO through June 13) 2011-12-02 11:12:24 PST
Comment on attachment 577047 [details] [diff] [review]
Patch v2

(In reply to Ms2ger from comment #3)
> I disagree. We rely on the default value of optional parameters pretty much
> everywhere we use optional parameters. I don't see how adding more
> complexity here is useful.

Looks like you're right. Sorry about that.

Still, if we're going to rely in this stuff, it should at least be documented. Can you update https://developer.mozilla.org/en/XPIDL to specify the default values (post XPCConvert) that we get when we omit optional arguments?

Also, please add a comment here noting that jsvals default to JSVAL_VOID (which converts to the NULL JSString) and integers default to zero:

> +    JSString *jsVersionStr = JS_ValueToString(aCx, aVersion);
> +    JSString *filenameStr = JS_ValueToString(aCx, aFilename);
> +    PRInt32 lineNo = aLineNo;

r+ with that. :-)
Comment 5 :Ms2ger 2011-12-06 11:50:08 PST
Created attachment 579394 [details] [diff] [review]
Patch v3

That version actually didn't really work out; this one passes try.
Comment 6 Bobby Holley (PTO through June 13) 2011-12-06 13:27:33 PST
Comment on attachment 579394 [details] [diff] [review]
Patch v3


>-
>-
>-    // Optional fourth and fifth arguments: filename and line number.
>-    if (filenameStr) {
>+    PRInt32 lineNo;
>+    if (optionalArgc >= 2) {
>+        JSString *filenameStr = JS_ValueToString(cx, filenameVal);
>+        if (!filenameStr)
>+            return NS_ERROR_INVALID_ARG;
>+
>+        JSAutoByteString filenameBytes;
>         if (!filenameBytes.encode(cx, filenameStr))
>             return NS_ERROR_INVALID_ARG;
>         filename = filenameBytes.ptr();
>+        lineNo = lineNumber;

The use of lineNumber here in the case of optional_argc == 2 might be correct here, but it looks suspicious given that the rest of the code depends on optional_argc.

As such, I'd prefer to structure this so that we first check optional_argc >= 2 (and do the filename stuff), then check optional_argc >= 3 (and save the filename). Afterwards, we check if optional_argc < 3, and if so, grab anything we're missing.

r+ with that.
Comment 7 :Ms2ger 2011-12-18 07:15:21 PST
(In reply to Bobby Holley (:bholley) from comment #6)
> Comment on attachment 579394 [details] [diff] [review]
> Patch v3
> The use of lineNumber here in the case of optional_argc == 2 might be
> correct here, but it looks suspicious given that the rest of the code
> depends on optional_argc.
> 
> As such, I'd prefer to structure this so that we first check optional_argc
> >= 2 (and do the filename stuff), then check optional_argc >= 3 (and save
> the filename). Afterwards, we check if optional_argc < 3, and if so, grab
> anything we're missing.

We agreed on IRC that this was fine.

https://hg.mozilla.org/mozilla-central/rev/935634dccf0c

Note You need to log in before you can comment on or make changes to this bug.