zealot has asked for the wisdom of the Perl Monks concerning the following question:

I am writing a script that needs to save it's state to a file and then load it in again later. I use the convention of using the S namespace to denote that the variable should be saved.

I am actually using a very light weight custom dumper function, but I was able to replicate the problem with the standard Data::Dumper library.

I was able to boil down the problem to this script:

#!/usr/bin/perl -T

use Data::Dumper;

$S::taint = $ARGV[0];

while (my ($name, $glob) = each %S::) {
    if (defined $$glob) {print Dumper($$glob)}
    print Dumper("$$glob") if (defined $$glob);
    print Dumper($$glob) if (defined $$glob);
}

[download]

In the while loop, the first and second line work just fine. However, the third line (which I happened to use) results in a fatal run-time error. Specifically Can't coerce GLOB to string in padsv at ./taint.pl line 10.

My version of Perl is: This is perl, v5.8.5 built for i386-freebsd-thread-multi-64int

Am I missing something, or if this an error somewhere with the Perl internals?

Thanks!

Replies are listed 'Best First'.
Re: Strange error dumping tainted data
by Stevie-O (Friar) on Mar 24, 2005 at 03:48 UTC
    I think you need to try another approach.

    Instead of using an 'S' namespace, try putting all the variables you need to save into a global hash (%::S will do). 

    use Storable;
$S{scalar} = 5;
@{$S{array}} = (5, 6, 7, 8);
%{$S{hash}} = (hi => 1, there => 2);

Storable::store \%S, 'state.sav';

%S = %{ Storable::retrieve('state.sav') };

    [download]
    (Note that for the purposes of saving and restoring variables, Storable has a number of advantages over Data::Dumper.)
    --Stevie-O 
    $"=$,,$_=q>|\p4<6 8p<M/_|<('=>
.q>.<4-KI<l|2$<6%s!<qn#F<>;$,
.=pack'N*',"@{[unpack'C*',$_]
}"for split/</;$_=$,,y[A-Z a-z]
         {}cd;print lc

    [download]
[reply]
[d/l]
[select]

      I am curious as to why you would suggest using a hash instead of a namespace. Is there a performance or security reason for changing it, or is it just a personal preference thing? There is a great deal of code already written using this method, so I wouldn't want to change it without cause. However, if there is a reason that it should be changed, I would definitly like to know! I was able to find a work-around, so my implementation is functional.

      I decided to use Data::Dumper instead of Storable for a couple of reasons. With another project, I had to rebuilt a lot of data after upgrading to a newer release of Perl that was not backwards compatible with the preious version of Storable. Also, I occasionally need to view and edit the information stored, and that is just easier with code that has been dumped.

      Thank you for the reply!

[reply]
Re: Strange error dumping tainted data
by dave_the_m (Monsignor) on Mar 24, 2005 at 13:36 UTC
    Looks like a perl bug. I'll have a closer look tonight.

    Dave.

[reply]
      Ah yes. It's been fixed in bleedperl, but hasn't been backported to the 5.8.x branch (because it involved a change to the ordering of the various SV types and so broke binary compatibility)

      Dave.

[reply]

        I appreciate knowing both that this was in fact a bug, and that is has actually already been fixed.

        Thank you for letting me know Dave!

[reply]

Back to Seekers of Perl Wisdom