I had googled a number of times, but the modperl list was able to
provide the answers to questions when I apparently couldn't google (nor
scour the archives) to find the answer. I can't believe I haven't
noticed this "unique" behavior before...
The short answer:
* This is unsupported syntax that Perl doesn't warn nor even blink at.
[It apparently should be obvious ;-)] Don't use statement modifiers
with my() declarations as the results are undefined (so much for
efficiency of syntax here and user friendliness, but I'm talking to
the wrong group for this gripe!).
For the record, I finally found this in the docs too:
Perl 5.8.6 perlsyn(1) says:
NOTE: The behaviour of a "my" statement modified with a statement
modifier conditional or loop construct (e.g. "my $x if ...") is
undefined. The value of the "my" variable may be "undef", any
previously assigned value, or possibly anything else. Don't rely on
it. Future versions of perl might do something different from the
version of perl you try it out on. Here be dragons.
Thanks everyone for their help!
Phil
--
Phillip E. Lobbes
[EMAIL PROTECTED]
PS. As I already knew, I should upgrade the software too... if only I
could convince the client to spend a little time on that!
Phil Lobbes <[EMAIL PROTECTED]> wrote:
> Software versions:
> mod_perl-1.99_12-2
> perl-5.8.3-17.5.legacy
> httpd-2.0.51-1.10.legacy
> Fedora Core 1 (kernel 2.4.22-1.2199.8.legacy.nptl)
>
> I have a custom application running under Apache::Registry w/mod_perl
> using strict and warnings everywhere.
>
> I have run into a case where sometimes a subroutine variable declared
> with my() inside an OO method retains its value somehow(!?!). I think I
> must be going crazy. The code looks like this:
>
> sub validate {
> my $app = shift;
> my $custid = $app->get_session_var('id') || "";
> my $sub_rec = $app->get_subscriber_rec($custid) if($custid);
> my $uid_int = $sub_rec->{'uid_int'} if($sub_rec);
>
> {
> no warnings 'uninitialized';
> warn("custid($custid) sub_rec($sub_rec) uid_int($uid_int)\n");
> }
> return $uid_int;
> }
>
> Output logged:
> custid() sub_rec() uid_int(4641)
>
> Somehow $uid_int has a value (4641 in this case) even though $sub_rec is
> not set!
>
> In theory this should be impossible, right? If $sub_rec is not set then
> $uid_int could ONLY be undef, right?
>
> I haven't yet setup a test platform that I can run this on repeatedly to
> see how reproducible this really is.
>
> I'm considering changing all code to explicitly set $sub_rec and
> $uid_int to undef first before doing anything else which should make
> this problem go away in theory, but if anyone sees something obvious
> here I'm missing please let me know.
>
> Sincerely,
> Phil
> --
> Phillip E. Lobbes
> [EMAIL PROTECTED]
