Calling an OP one has made oneself gives strange error #1052
Labels
CC.resolved
Issue with CureCode status built, tested or complete
Datatype: function!
Oldes.resolved
Bugs/wishes with Oldes' fixes/features
Ren.resolved
Status.important
Test.written
Type.bug
Submitted by: meijeru
See #1051, and the code hereunder.
Imported from: CureCode [ Version: alpha 66 Type: Bug Platform: All Category: n/a Reproduce: Always Fixed-in:alpha 67 ]
Imported from: metaeducation#1052
Comments:
Submitted by: BrianH
The error is that make op! [[][]] works at all - it should throw an error.
The OP function should be the only way to create a value of that type. If the MAKE action works badly with this specs, then trial and error would eventually lead to specs that work, which would allow recreation of these functions in REBOL code when they are otherwise intentionally inaccessible. This would be a major security hole.
As it is, the behavior of the make action of this types suggests that the resulting function accesses memory badly. This is a worse situation than #1051, where at least the function crashes REBOL. Here, you are apparently able to successfully access a value in memory that doesn't crash the interpreter right away. This means that this is a potential security hole with this spec, let alone some theoretical other spec not yet found.
Submitted by: Carl
For 3.0.0 - MAKE of op! will now throw an error. However, R3 has been designed to allow user-defined ops... but that feature will be deferred until a future release.
Submitted by: BrianH
The OP function should be good for making user-defined ops when that feature comes. Is it intended that the function redirected to must be of the action! type, as it is for all current ops?
Make OP! does not appear to raise an error in R3-Alpha open source release, and gives the error shown.
Ren-C has changed this completely and has a full means for specifying functions that acquire their argument from the left. There is no OP! (there is only one FUNCTION! type overall), however that function may be associated with a word in SET via an ENFIX binding. This has yielded some very interesting results.
The text was updated successfully, but these errors were encountered: