REBOL3 tracker
  0.9.12 beta
Ticket #0001515 User: anonymous

Project:



rss
TypeBug Statusbuilt Date9-Mar-2010 12:27
Versionalpha 97 CategoryError Handling Submitted byBrianH
PlatformAll Severityminor Prioritynormal

Summary Unwind values are assignable with set-word expressions, SET or SET/any
Description When there is an assignment statement in the evaluation flow of an unwind function (BREAK, CONTINUE, THROW, RETURN or EXIT), the assignment actually happens and the word is set to the unwind pseudo-error value. Strangely enough it doesn't interfere with the unwinding process. Presumably when the assign returns the value being assigned (for chaining) the unwind propagation can continue. Still, the assignment should not happen in this case, since it could be a major security hole (see the example and #1004). Perhaps related to bug #1509.

The preferred course of action would be for the assignment to not happen in this case, just propagate the unwind. That would allow regular errors to be assigned, but would not assign unwinds.
Example code
; Proof that the error is assigned
>> a: make error! "Hello" form a
== {** User error: "Hello"
}

; Note that the break happens - the error is printed, not formed
>> a: break form a
** Throw error: no loop to break

; Proof that the break unwind was assigned above
>> form a
== {** Throw error: no loop to break
** Where: form
** Near: form a
}
; Note that the unwind was evaluated before the FORM,
; not formed as is. You can tell by the Where and Near
; fields of the error. This is a bad sign.

; Why this is bad: You can use that value to replicate the BREAK function
>> do a
** Throw error: no loop to break
>> loop 1 [do a print "Good"]
>>
; If you are sandboxing the unwind functions, this will break the sandboxing.

Assigned ton/a Fixed inr3 master Last Update19-Feb-2014 20:03


Comments
(0002085)
Ladislav
10-Mar-2010 10:39

it is not counterintuitive to R2 users; it always worked:

>> error? a: try [1 / 0]
== true
(0002086)
Ladislav
10-Mar-2010 10:42

"...It only seems to work with untriggered regular errors and unwinds." - the #771 as well as #1509 both mention, that it is a bug to "leak" triggered errors/unwinds into the Rebol value space, as opposed to untriggered errors/unwinds, where it is OK.

Fortunately, taking into account, how error propagation is implemented, triggered regular errors cannot leak into the Rebol value space, only unwinds can.
(0002089)
BrianH
11-Mar-2010 19:32

Weird, I've been using SET/any for years to work around this. When did it start working this way in R2? It's always strange when you find out that a standard workaround that you've been doing for an old bug isn't necessary because at some point the bug got fixed without anyone telling you :)

I can't dismiss this ticket until #1509 is fixed; until then it is a major security bug. Summary changed accordingly.
(0002758)
Ladislav
2-Nov-2010 12:30

in the core-tests suite
(0003395)
BrianH
23-Jan-2013 22:47

Based on further testing, SET and SET/any also assign the unwind values, so I changed the summary, description and core-tests suite accordingly. Having the unwind value be passed to the SET function at all is bug #1509, but once it gets the unwind value it certainly shouldn't assign it to anything.

Date User Field Action Change
19-Feb-2014 20:03 BrianH Status Modified reviewed => built
19-Feb-2014 20:03 BrianH Fixedin Modified => r3 master
23-Jan-2013 22:47 BrianH Comment : 0003395 Added -
23-Jan-2013 22:44 BrianH Status Modified submitted => reviewed
23-Jan-2013 22:44 BrianH Description Modified -
23-Jan-2013 22:44 BrianH Summary Modified Unwind values are assigned with set-word expressions => Unwind values are assignable with set-word expressions, SET or SET/any
2-Nov-2010 12:30 Ladislav Comment : 0002758 Added -
18-Apr-2010 21:34 BrianH Comment : 0002089 Modified -
18-Apr-2010 21:34 BrianH Summary Modified Error values are assigned with set-words => Unwind values are assigned with set-word expressions
11-Mar-2010 19:32 BrianH Comment : 0002089 Added -
10-Mar-2010 10:45 Ladislav Comment : 0002086 Modified -
10-Mar-2010 10:43 Ladislav Comment : 0002086 Modified -
10-Mar-2010 10:42 Ladislav Comment : 0002086 Added -
10-Mar-2010 10:39 Ladislav Comment : 0002085 Added -
9-Mar-2010 12:39 BrianH Code Modified -
9-Mar-2010 12:39 BrianH Description Modified -
9-Mar-2010 12:27 BrianH Ticket Added -