Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

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

by Zaxo (Archbishop)
on Apr 05, 2005 at 02:57 UTC ( #444844=note: print w/replies, xml ) Need Help??


in reply to Re: Writing general code: real world example - and doubts!
in thread Writing general code: real world example - and doubts!

++ 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; };
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

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 dieing places.

    Flavio (perl -e "print(scalar(reverse('ti.xittelop@oivalf')))")

    Don't fool yourself.

      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

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://444844]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others perusing the Monastery: (4)
As of 2019-09-15 05:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    The room is dark, and your next move is ...












    Results (178 votes). Check out past polls.

    Notices?