forward-incompatible Function.prototype.toString requirement

Juriy Zaytsev kangax at gmail.com
Fri Apr 17 14:10:11 UTC 2015


I did some research on this just last year —
http://perfectionkills.com/state-of-function-decompilation-in-javascript/
(and originally back in 2009, when things were much wilder,
http://perfectionkills.com/those-tricky-functions/)

Corresponding tests with notes —
http://kangax.github.io/jstests/function-decompilation/

Just few days ago, I've been also thinking to add tests to ES6 compat table
checking these exact (ES6 introduced) "toString representation
requirements" from 19.2.3.5.

-- 
kangax

On Thu, Apr 16, 2015 at 4:33 PM, Mark S. Miller <erights at google.com> wrote:

> I agree with all this. Let's gather current precedent across JS
> implementations of function printings are not and should not be parseable
> and see if we can extract a clear spec that is consistent enough with
> current reality.
>
>
> On v8:
> > Object
> function Object() { [native code] }
> > Object.bind(Object)
> function () { [native code] }
>
> On SpiderMonkey:
> > Object
> function Object() {
>     [native code]
> }
> > Object.bind(Object)
> function Object() {
>     [native code]
> }
>
> On JSC:
> > Object
> function Object() {
>     [native code]
> }
> > Object.bind(Object)
> function Object() {
>     [native code]
> }
>
>
> Looks promising so far! Anyone care to do a more complete investigation
> and write up an initial proposal?
>
>
>
>
> On Thu, Apr 16, 2015 at 7:13 AM, Frankie Bagnardi <f.bagnardi at gmail.com>
> wrote:
>
>> I just meant that it seems confusing that it can both produce a FunctionExpression
>> and "return a string for which eval will throw a SyntaxError exception."
>>
>> I didn't mean to highjack this thread; the concern in the original email
>> is noteworthy.  There should be recommended syntaxes which future versions
>> of the spec agree not to break, including current browser implementations.
>> This gives any future engines, or modifications to current engines a
>> clearly defined acceptable way to format these strings.
>>
>> This also gives libraries which parse functions at runtime (despite how
>> good of an idea this is) quick bail cases without using eval.  Examples of
>> this are angular and require.js.
>>
>>
>>
>> On Thu, Apr 16, 2015 at 6:55 AM, Mark S. Miller <erights at google.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 16, 2015 at 6:36 AM, Andreas Rossberg <rossberg at google.com>
>>> wrote:
>>>
>>>> On 16 April 2015 at 14:34, Frankie Bagnardi <f.bagnardi at gmail.com>
>>>> wrote:
>>>>
>>>>> The part that sticks out to me is... toString on functions currently
>>>>> throws a syntax error when eval'd for non-named functions.  Tested in
>>>>> chrome:
>>>>>
>>>>> var f = function(){ return 1 };eval(f.toString()); // SyntaxError
>>>>> // becausefunction(){ return 1 }; // SyntaxError
>>>>> // but, force an expression: eval("(" + f.toString() + ")") // essentially clones f
>>>>>
>>>>>>>>>> This... is confusing in my opinion.
>>>>>
>>>>
>>>> Yeah, the spec says:
>>>>
>>>> "The string representation must have the syntax of a
>>>> FunctionDeclaration FunctionExpression, GeneratorDeclaration,
>>>> GeneratorExpression, ClassDeclaration, ClassExpression, ArrowFunction,
>>>> MethodDefinition, or GeneratorMethod depending upon the actual
>>>> characteristics of the object."
>>>>
>>>> which is weird. First, it doesn't really make sense, because whether
>>>> something originates from a declaration vs expression isn't a
>>>> "characteristic of the object". Second, making it return different
>>>> syntactic classes in different cases is not particularly useful for your
>>>> case.
>>>>
>>>> But then again, using the result of f.toString as input to eval is A
>>>> REAL BAD IDEA anyway; toString should only be used for diagnostics, not
>>>> programmatically, because that is meaningless in general. So I personally
>>>> don't mind the friction.
>>>>
>>>
>>> Disagree. The purpose of this change in toString spec from ES5 is
>>> primarily to support pass-by-copy closed functions. The intent was that it
>>> always work to evaluate them as expressions, i.e., with the surrounding
>>> parens.
>>>
>>> http://wiki.ecmascript.org/doku.php?id=harmony:function_to_string
>>> http://wiki.ecmascript.org/doku.php?id=strawman:concurrency#there
>>>
>>>
>>>
>>>
>>>>
>>>> /Andreas
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Thu, Apr 16, 2015 at 2:56 AM, Andreas Rossberg <rossberg at google.com
>>>>> > wrote:
>>>>>
>>>>>> On 16 April 2015 at 11:34, Michael Ficarra <
>>>>>> mficarra at shapesecurity.com> wrote:
>>>>>>
>>>>>>> ES2015 section 19.2.3.5 (Function.prototype.toString) places four
>>>>>>> restrictions on the output of Function.prototype.toString, one of which is
>>>>>>>
>>>>>>> If the implementation cannot produce a source code string that meets
>>>>>>>> these criteria then it must return a string for which *eval* will
>>>>>>>> throw a *SyntaxError* exception.
>>>>>>>>
>>>>>>>
>>>>>>> What is a SyntaxError today may not be a SyntaxError tomorrow. How
>>>>>>> can an implementation return a string that will satisfy this requirement in
>>>>>>> the future when the language has added new syntax? Does the committee have
>>>>>>> a SyntaxError recommendation that can be added as a non-normative note to
>>>>>>> that section?
>>>>>>>
>>>>>>
>>>>>> In the (probably unlikely) case that the language changed that way,
>>>>>> and an affected implementation adopted that change, then it would simply
>>>>>> have to change its toString implementation accordingly at that point. I
>>>>>> don't see a problem there.
>>>>>>
>>>>>> /Andreas
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss at mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>>
>>> --
>>>     Cheers,
>>>     --MarkM
>>>
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150417/07dffee4/attachment-0001.html>


More information about the es-discuss mailing list