[PPC0036] Add document about Viral Value Magic#90
Conversation
|
|
||
| * When calculating a new value as a result of one *or more* input values that have these annotations attached, the `infect` function on each annotation of each such value is invoked to copy it into the resulting destination. It may be that the result ends up with more than one annotation attached to it. | ||
|
|
||
| * When a container variable is `local`ised, magic annotations of this shape are not copied into the new temporary container. |
There was a problem hiding this comment.
this behavior doesn't match with what i'd have in my head - i'd imagine that unless mutated, a local-ised copy would continue being the same thing.
perhaps our mental models are not aligned - could you spell out specifically why you want this behavior?
There was a problem hiding this comment.
We may need to have a sharper distinction between value and container magic before trying to make value magic viral.
There was a problem hiding this comment.
When you local a variable, the internals of how it works means that you get a new SV that gets moved into place for where that variable was visible. This means that magics that ought to be considered part of the "container" (things like the special behaviours of the various dollar-punctuation variables) needs to be copied onto that new SV as well, so that "the SV visible as that variable" retains that behaviour.
Whereas, any behaviours that are part of the value currently stored in the SV should not get copied into that new one; they belong with the value rather than the variable that contains it.
There was a problem hiding this comment.
We may need to have a sharper distinction between value and container magic before trying to make value magic viral.
Perhaps so. I try to make more of a distinction of that in Magic-v2 (see the corresponding PPC0035). With v1 you basically just distinguish by being PERL_MAGIC_ext vs PERL_MAGIC_extvalue and that has effects on localisation, whereas magic-v2 has a specific MGv2f_CONTAINER flag to properly say "this relates to the container, not the value stored in it".
|
|
||
| struct ScalarValueMagicFunctions { | ||
| ..., /* existing fields, where shape == MGv2s_SCALARVALUE */ | ||
| void (*infect)(pTHX_ SV *ssv, MAGIC *smg, SV *dsv, MAGIC *dmg); |
There was a problem hiding this comment.
I'm sure we can find a better name than that.
There was a problem hiding this comment.
Likely so; this was just a unique name that came to mind that would be pretty easy to search-replace later on.
There was a problem hiding this comment.
Maybe propagate is better? It's a slight overlap with the thing that exception objects do on rethrow...
|
|
||
| Normally, this section is used to explain around any potential security *problems* that might be introduced by the changes proposed by such a document. As is typical when considering adding new low-level abilities that modules can build on top of, the answer is usually "none foreseen, they would have to be considered by the modules being built". | ||
|
|
||
| But a much better answer here is to observe that this proposed mechanism adds a great ability to introduce new *solutions* to security problems. As perhaps was already hinted at in the introduction, the mechanism proposed here acts similar to but is more flexible and powerful than perl's existing "taint" behaviour, which was primarily intended for its security-related purposes. In practice, that mode is seldom used, because of its lack of flexibility. Taint mode just stores a single boolean annotation about any particular value ("is this considered tainted?"), which affects certain entirely-internal functions and operations. In contrast, this proposal would easily permit the creation of a more flexible set of policies; see the "Supertaint" example below. |
There was a problem hiding this comment.
I think it's very different from taint, I'm not sure it can actually replace that logic; taint works much more indirect that this would.
3 participants
No description provided.