Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • For the benefit of others reading your journal that don't fully understand why this is probably not an easy thing to do....

    sub double { 2 * $_[0] }

    Seems straight forward enough and shouldn't have any side effects. Hrm, what if $_[0] is an alias to a tied variable. What if the FETCH method of that variable has action at a distance. Can't tell just by looking at the source :-(

    • Which is exactly why you'd at very least need the optree.

      Something Alias taught me with PPI is that analyzing Perl source is so dang hard partially because of the potentially hidden external factors that can change what a particular line means.

      What you've shown extremely well above is that a document parser is probably the wrong way to do side-effect analysis.
      • I don't think the optree holds that information, as it's the opcodes themselves that have to check for magic. At compile time, Perl doesn't know if you'll pass in a variable with magic.

        • Ah, true. My limited knowledge of the internals is showing. :)
        • All rules cease to be valid as soon as an overloaded value or other unexpected get/set magic is invoked. This means I either need to guess that any operation can do anything or pretend it's not a problem and hope I get a useful answer anyway.
    • It also ocurrs to me that the tainting infrastructure might be useful to look at, because it's another example of looking at how operations propagate properties. Althought it most likely operates at the wrong level of abstraction.
      • FYI, Tainting is a property of values, not code.
        • I realize that. What I was proposing is that we already have a mechanism for determining which expressions propagate taintedness. I was thinking of something that, once data that was a result of a side effect was used, you might be able to use the same mechanism to determine what code was dependent on that side effect.

          Then again, I need to brush up on my internals knowledge before I make any more pi-in-the-sky proposals. :)
    • I can tell you without looking at the source that there's a side-effect. $_[0] is going to be used in numerical context, so $_[0] will get its IOK flag (and its IVX value) set. (Effectively, this may turn out to be a no-op, but the potential is there).

      It's really, really hard to do anything meaningful in Perl that doesn't have side-effects.

      • How would these flags being set be visible to the Perl program? Does this mean simply using a variable a particular way in one expression can change how it's treated in other expressions?
        • Yes. The first thing that comes to mind is that it may affect the behaviour of the bitwise ops. There are more examples of subtle effects; I can’t think of them right now, but I know I used to know about them.