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

use Perl Log In

Log In

[ Create a new account ]

Journal of jjore (6662)

Wednesday October 25, 2006
10:35 AM

Side effect detection?

[ #31415 ]

I'm pondering whether it's sane to look at optrees and make statements about what external things they examine and what external things they modify. I'd like to know whether a function or block has side effects.

This has two purposes: the parallelization flamewar on perlmonks and deobfuscation. If I can tell what a piece of code depends on then I can decide whether to run it in a specific order or not. I've long wanted to have a lazy map and I know I get one in perl 6 but I'm impatient and I think I want to wait til I get a comfy workstation before I dive into it.

I think it'd also be super nifty to know that an expression or function or whatever is staticly defined and can be executed and eliminated during deobfuscation.

I'm thinking of just making a catalog of the things different ops read from and write to. Then a query is just asking what any given node cares about plus all of it's children. Simple, right?

I figure there's some ops I really just want to treat as blackboxes and it'd be easy to start things out that way as a default: everything is a blackbox til more information is added to the catalog.

I kind of doubt I'll post this to CPAN or even bother writing it. I have enough other things I haven't gotten to yet or synched with CPAN that I ought to do first before trying something new and likely to fail.

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.