Re: modification of read-only in hash ++

[rob_au]

in reply to modification of read-only in hash ++

The BEGIN block is executed prior to the definition of the %guid and as such the hash element $guid{218827} is auto-vivified in this code block. The auto-vivified hash element has an undefined value which you are subsequently attempting to increment.

For details on the behaviour of BEGIN blocks, see the perlmod man page under the heading "Package Constructors and Destructors". For an explanation of auto-vivification, see perlref, perlfaq4, perlfunc and the node Autovivification by merlyn.

Update: Erk, weirder stuff appearing - It almost looks like something weird is happening with closures ...

[Abigail-II]

I don't understand. Why would $guid{218827} be auto-vivified? Note that $guid{218827} is referenced from a subroutine, which isn't executed until after the BEGIN block.

I think there's a bug in Perl. Watch what happens if you dump the content of %guid in the BEGIN block:

#!/usr/bin/perl
     
use warnings;
         
            
my %guid=(218827=>5,109940=>2);
          
BEGIN 
{
    %handle=
    (
        cmd => sub
        {
            my $ref = sub{$guid{218827}++;warn "sub: $guid{218827}";};
            $ref->();
        },
    );
    while (my ($key, $value) = each %guid) {
        print defined $key ? $key : "UNDEF";
        print ":";
        print defined $value ? $value : "UNDEF";
        print "\n";
    }
}        
            

$handle{cmd}->();
__END__
sub: 6 at buu line 14.

Not only does it show that the BEGIN block doesn't autovivify the value, the error disappears as well!

In fact, just about any reference to %guid (like keys %guid;, %guid;, or $guid {1};) after the assignment to %handle makes the error go away.

This ought to be perlbugged.

Abigail

[ysth]

It appears to be fixed in bleadperl. Nevertheless, a bug report with a short test case (or patch to the t/op/closure.t) would be good.