Side effect detection?

jjore on 2006-10-25T15:35:41

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.


Example of why this is hard

Limbic Region on 2006-10-25T19:06:57

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 :-(

Re:Example of why this is hard

DAxelrod on 2006-10-25T20:54:28

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.

Re:Example of why this is hard

chromatic on 2006-10-26T07:56:49

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.

Re:Example of why this is hard

DAxelrod on 2006-10-26T18:07:01

Ah, true. My limited knowledge of the internals is showing. :)

Re:Example of why this is hard

jjore on 2006-10-26T19:11:50

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.

Re:Example of why this is hard

DAxelrod on 2006-10-25T20:57:06

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.

Re:Example of why this is hard

jjore on 2006-10-26T15:21:25

FYI, Tainting is a property of values, not code.

Re:Example of why this is hard

DAxelrod on 2006-10-26T18:10:04

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. :)

Re:Example of why this is hard

Abigail on 2006-10-27T07:24:26

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.

Re:Example of why this is hard

DAxelrod on 2006-10-28T04:08:11

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?

Re:Example of why this is hard

Aristotle on 2006-10-28T04:55:42

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.