You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Um, sorry, you are missing the other part of the R2 behavior: What you propose to have DO do if passed a word value with a function assigned to it, executing the function, R2's DO also does with blocks or parens assigned to the words - even DO evaluating an inline word doesn't do something like that. It's a pretty severe unfixable bug in R2 because of backwards compatibility. Also, I notice that all of the example code in your poll had no side effects and took no parameters, let alone use words with blocks assigned to them, so the vote doesn't really count as much as you think.
In R2:
>>a: does [print"pwned!"]
>> do 'a
pwned!; DO of a word! assigned a function executes the function, like inline word evaluation
>>a: [print"pwned!"]
== [print"pwned!"]
>> do 'a
pwned!; DO of a word! assigned a block executes the block, completely inconsistent with inline word evaluation
>>a: func[:x y] [set:x:yinsert clear :y"bye-bye data!"print"pwned!"]
>> do 'a b: [valuable data]
pwned!>> b
== ["bye-bye data!"]
; DO of a word! allows get-word hacking!
In the mezzanine code, DO of an arbitrary function value is considered to be an unsafe practice since you can hack the code of functions using get-word parameters. At least when doing blocks and parens we can be sure that they take no parameters, so they are at least safe to call (SECURE, PROTECT and binding tricks ensure they are safe to run). For function values we use APPLY to prevent hacking, or more often we screen them out altogether categorically.
For words, there is no APPLY. We can screen them out by only allowing block! and paren!, sometimes. Adding the feature you request would add word! to the set of types that it wouldn't be safe to DO without data flow analysis or a lot of screening code.
The consistency argument (your first bullet point) is not a bad one, as long as we are really specific about what we want to be consistent with. Following the pattern of your proposed behavior for lit-words in #1434, and that of parens, it seems that it would be reasonably safe for all word and path types to have this:
>> do :some-word-or-path-value
be treated the same asthis:>> do reduce [:some-word-or-path-value]
The putting-it-in-a-block-by-itself restriction in the equivalence is important. Note that a set-word or set-path evaluated by itself in a block would trigger an error, so DO of a set-word or set-path value should also trigger an error, though not necessarily the same one (see #1883 for details). And a word or path that refers to a function would trigger an error if the function takes parameters, but not otherwise. Both of these errors reduce the attack surface of calling code, so malicious words and paths can't get access to the original version of a function body and inject code or see hidden contexts and bindings. This would make words and paths no more unsafe to DO than parens or blocks.
The behavior of R2's DO path! follows this model pretty well, so it might not be a bad idea to emulate. See #1881 for details.
When deciding about a language feature you need to not only consider how it will be used in the best case, but how it will be used in the worst case. How much screening code will you need to add to make the feature safe to use in your code? How does the amount and awkwardness of the code plus its screening guards compare to the code to do the equivalent behavior without the feature? What does the feature add that you couldn't do before? Hopefully this comment can help with this evaluation.
Rebolbot commented on May 3, 2011:
Submitted by:Ladislav
"DO of a word! assigned a block executes the block, completely inconsistent with inline word evaluation "
I did not try to discuss that in this ticket. Please, let me know if the summary does not suffice to explain the subject of the ticket in an understandable way.
Rebolbot commented on May 3, 2011:
Submitted by:BrianH
"* the users find the R2 behaviour perfect and more logical "
That is the part that discusses that subject. The example is misleading.
Rebolbot commented on May 3, 2011:
Submitted by:Ladislav
Changed the formulation to "the users find the R2 behaviour when processing the example code perfect and more logical" to underline that the ticket relates to the summary. Otherwise, there are many examples when REBOL users don't find the R2 behaviour perfect and logical.
Rebolbot commented on May 3, 2011:
Submitted by:Ladislav
"...and since you've requested that lit-word! and lit-path! be returned to their R2-style..."
I did not request that
Rebolbot commented on May 5, 2011:
Submitted by:BrianH
Updated the comment accordingly, and in accordance with the conclusions reached in #1434. #1881 has some more explanation of why the limits of R2's DO path! are a good idea to follow, and #1883 deals with the same issue for DO set-path!.
Rebolbot commented on Feb 27, 2014:
Submitted by:BrianH
Note: I am working on an implementation of this and #1881, with this behavior:
>> do :some-word-or-path-value
be treated the same asthis:>> do reduce [:some-word-or-path-value]
Coming soon.
Rebolbot commented on Jan 6, 2016:
Submitted by:Ladislav
BrianH: "DO of a word! assigned a block executes the block, completely inconsistent with inline word evaluation" - yes, and completely consistent with explicit evaluation
Rebolbot commented on Jan 6, 2016:
Submitted by:Ladislav
BrianH: "DO of a word! allows get-word hacking!" - you must be joking, how exactly does crippling the functionality of DO in this way prevent simpler:
Submitted by: Ladislav
I asked REBOL users what did they prefer as the result of the example code below.
All of them preferred to get the string! datatype like in R2, with only one exception, Brian Hawley preferring to obtain the function! like in R3.
Reasons for the preference were:
Imported from: CureCode [ Version: alpha 111 Type: Wish Platform: All Category: Native Reproduce: Always Fixed-in:none ]
Imported from: metaeducation#1882
Comments:
Submitted by: BrianH
Um, sorry, you are missing the other part of the R2 behavior: What you propose to have DO do if passed a word value with a function assigned to it, executing the function, R2's DO also does with blocks or parens assigned to the words - even DO evaluating an inline word doesn't do something like that. It's a pretty severe unfixable bug in R2 because of backwards compatibility. Also, I notice that all of the example code in your poll had no side effects and took no parameters, let alone use words with blocks assigned to them, so the vote doesn't really count as much as you think.
In R2:
In the mezzanine code, DO of an arbitrary function value is considered to be an unsafe practice since you can hack the code of functions using get-word parameters. At least when doing blocks and parens we can be sure that they take no parameters, so they are at least safe to call (SECURE, PROTECT and binding tricks ensure they are safe to run). For function values we use APPLY to prevent hacking, or more often we screen them out altogether categorically.
For words, there is no APPLY. We can screen them out by only allowing block! and paren!, sometimes. Adding the feature you request would add word! to the set of types that it wouldn't be safe to DO without data flow analysis or a lot of screening code.
The consistency argument (your first bullet point) is not a bad one, as long as we are really specific about what we want to be consistent with. Following the pattern of your proposed behavior for lit-words in #1434, and that of parens, it seems that it would be reasonably safe for all word and path types to have this:
The putting-it-in-a-block-by-itself restriction in the equivalence is important. Note that a set-word or set-path evaluated by itself in a block would trigger an error, so DO of a set-word or set-path value should also trigger an error, though not necessarily the same one (see #1883 for details). And a word or path that refers to a function would trigger an error if the function takes parameters, but not otherwise. Both of these errors reduce the attack surface of calling code, so malicious words and paths can't get access to the original version of a function body and inject code or see hidden contexts and bindings. This would make words and paths no more unsafe to DO than parens or blocks.
The behavior of R2's DO path! follows this model pretty well, so it might not be a bad idea to emulate. See #1881 for details.
When deciding about a language feature you need to not only consider how it will be used in the best case, but how it will be used in the worst case. How much screening code will you need to add to make the feature safe to use in your code? How does the amount and awkwardness of the code plus its screening guards compare to the code to do the equivalent behavior without the feature? What does the feature add that you couldn't do before? Hopefully this comment can help with this evaluation.
Submitted by: Ladislav
I did not try to discuss that in this ticket. Please, let me know if the summary does not suffice to explain the subject of the ticket in an understandable way.
Submitted by: BrianH
That is the part that discusses that subject. The example is misleading.
Submitted by: Ladislav
Changed the formulation to "the users find the R2 behaviour when processing the example code perfect and more logical" to underline that the ticket relates to the summary. Otherwise, there are many examples when REBOL users don't find the R2 behaviour perfect and logical.
Submitted by: Ladislav
I did not request that
Submitted by: BrianH
Updated the comment accordingly, and in accordance with the conclusions reached in #1434. #1881 has some more explanation of why the limits of R2's DO path! are a good idea to follow, and #1883 deals with the same issue for DO set-path!.
Submitted by: BrianH
Note: I am working on an implementation of this and #1881, with this behavior:
Coming soon.
Submitted by: Ladislav
BrianH: "DO of a word! assigned a block executes the block, completely inconsistent with inline word evaluation" - yes, and completely consistent with explicit evaluation
Submitted by: Ladislav
BrianH: "DO of a word! allows get-word hacking!" - you must be joking, how exactly does crippling the functionality of DO in this way prevent simpler:
a b: [valuable data]?
The text was updated successfully, but these errors were encountered: