develooper Front page | perl.perl5.porters | Postings from October 2003

Re: [perl #24296] scalars and hashes sometimes not available in quoted evals in END blocks

Thread Previous
From:
David Dyck
Date:
October 29, 2003 23:04
Subject:
Re: [perl #24296] scalars and hashes sometimes not available in quoted evals in END blocks
Message ID:
Pine.LNX.4.51.0310292111560.10314@dd.tc.fluke.com
On Tue, 28 Oct 2003 at 20:11 -0000, Dave Mitchell <perlbug-followup@perl.or...:

> The behaviour of closures is severely under-documented at the moment.
> One of the things on my copious list of things to do is to write it up
> properly sometime. Under that hypothetical documentation, the behaviour of
> your code correct ;-)

Thanks, I hope it does get documented.

[[ quick summary --
    this bug could be used a a placeholder to note that
    my and our variable life ends at different points in the program,
    and that my variables may not be accessable in eval q{} blocks,
    while our variables might be,
   then again - you might just want to reject it :-), but
   thanks again for spending the time to discuss it. ]]

> Part of the problem is that you are using a combination of two edge
> features, both of which can do funny things with closures. First, eval
> can't always do the right thing, because Perl doesn't necessarily know at
> the time that the statement containing the 'eval' was compiled, that the
> eval may later refer to some outer lexicals that therefore need preserving
> beyond their normal lifespan.  Second, END is called vary late, when some
> things no longer exist that that you may want to rely upon.

Some the the problems that I've expressed with this bug report were
worked around by changing the "my" to "our" variables, but why should
"my" variables be destroyed before "our" variables, and why
should either of them be destroyed before all the END blocks
have been processed?  In the case that started me down this
path, I needed to know some information, and have it processed
at the END.


I would think that others would like to find that their
variables also have not yet become unaccessable in their END blocks.

Here's a "C" analogy, where variables (and files) are still
open during the atexit processing.  (it doesn't fit all the way,
but it does show how one might want a variable to exist after
after exit is called;

dd:end$ gcc endexit.c
dd:end$ ./a.out
e(), s=done
dd:end$ cat endexit.c
#include <stdio.h>
#include <stdlib.h>

char *s="init";

void e(void)
{
    printf( "e(), s=%s\n", s );
}

int main(void)
{
    atexit(e);
    s = "done";
}

 ....

Here's another perl program that illustrates another
part of variable life that I would like to see documented
(IN YOUR SPARE TIME OF COURSE :-)
The perl code declares a my variable $s, that has a short life
and it too doesn't make it to the END block, and the sub xxEND
first sees the variable, then later does not.



use strict;
use warnings;
$| = 1;


my $s .= "init";
warn "1 s=$s\n";

$s = "post init";
warn "2 s=$s\n";

BEGIN {
    eval q{
	warn "BEGIN s=$s\n";
	$s = "in BEGIN";
    };
}

eval q{
    warn "3  s=$s\n";
    $s = "done";
    warn "4  s=$s\n";
};


sub xxEND {
    eval q{
	warn "xxEND s=$s\n";
	$s = "in END a";
    };
}

xxEND;

END {
	warn "END\n";
	xxEND;
}

__END__
Use of uninitialized value in concatenation (.) or string at (eval 1) line 2.
BEGIN s=
1 s=in BEGINinit
2 s=post init
3  s=post init
4  s=done
xxEND s=done
END
Variable "$s" is not available at (eval 4) line 2.
Use of uninitialized value in concatenation (.) or string at (eval 4) line 2.
xxEND s=

Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About