Re^2: Writing general code: real world example

++ your observation on not giving an out on detainting.

I've got a solution to detainting which I think is very well suited to refactoring old code. It can be retrofitted as a single chunk of initialisation code, and old code will automatically validate and detaint the rigged variable on every assignment or modification.

use Tie::Constrained qw/detaint/;
tie my $var, 'Tie::Constrained', sub {
    my $re = qr/whatever/;
    $_[0] =~ /$re/ and &detaint;
};
[download]

Later, when you say, $var = $tainted_thing; $var is validated and untainted, while $tainted_thing remains tainted and unmodified. The trick is that the &detaint call acts on an anonymous copy of $tainted_thing's value just before assignment to $var. (Tie::Constrained::detaint() is almost identical to frodo72's original detaint()).

This does not address OP's excellent question about generalizing his detaint routine. I question the value of that as a general practice, but it may be useful for an application which must iterate over a bunch of similar-type values.

After Compline,
Zaxo

Comment on Re^2: Writing general code: real world example - and doubts! Select or Download Code

Replies are listed 'Best First'.
Re^3: Writing general code: real world example - and doubts! by polettix (Vicar) on Apr 05, 2005 at 08:52 UTC
Meditation are good for meditating - so this thread is teaching me something about refactoring (which is theoretical), and something about tainting (which is practical). This is good for me. I like very much your solution. In particular, it makes me reflect that an in-place detainting could be dangerous, because I could end up not knowing whether a variable has already been detainted or not. Your approach seems to divide variables into two groups: tainted and not, and this seems reasonable. I only wonder how readability could be affected by this approach. The detainting method being under the surface, I fear that the naive programmer (er.. me) could be disorientated by seeing such an assignment and seeing `$var` used in potentially `die`ing places. Flavio (perl -e "print(scalar(reverse('ti.xittelop@oivalf')))") Don't fool yourself.	[reply] [d/l] [select]
Re^4: Writing general code: real world example - and doubts! by Zaxo (Archbishop) on Apr 05, 2005 at 09:09 UTC
You're right, readability suffers with that approach. Because code is invoked at a distance, and there is no local indication of which variables are covered by the validation mechanism, the reader needs to absorb the ties before getting to the real code. That's likely to be missed by a maintainer. Documentation helps, comments help, but those may not be enough. You spotted the principal weakness. I'm not yet encouraging anyone to use Tie::Constrained in production. The API is not yet stable, simple as it is. I'll make a version 1.00 release when I think it's ready. If you have suggestions, I'd welcome them. After Compline, Zaxo	[reply]


Problems? Is your data what you think it is?
	PerlMonks

Re^2: Writing general code: real world example - and doubts!