Le Mer 08 Mar 2017 04:26:39, therealryan@gmail.com a écrit :
Show quoted text> Howdy
>
> System details: Perl 5.20.2 on Debian Jessie.
>
> I would expect the following program to die on line 19, but it doesn't:
>
> use 5.014;
> use strict;
> use warnings;
> no autovivification;
>
> {
> my $foo = undef;
> my $thing = $foo->{bar};
>
> # this does not die, as expected
> die if defined $foo;
> }
>
> {
> my $foo = undef;
> do_nothing( $foo->{bar} );
>
> # I would expect this to die, but it doesn't - $foo has been autovivified
> die unless defined $foo;
> }
>
> sub do_nothing {
> return undef;
> }
>
> If this is expected behaviour then it seems like a notable caveat to the
> purpose of the 'no autovivification' pragma, and should be documented as
> such.
>
> Thanks!
Hello,
This behaviour is expected, and nothing can reasonably be done in autovivification.pm to alter it. Since Perl subroutine arguments are passed by alias, the argument list is tagged as "modifiable" by the perl interpreter, in case your do_nothing() sub assigns something to its argument. There's no way for perl to know at compile-time whether that's the case or not. The same reasoning holds for loops.
You can forbid this kind of autovivification with the 'store' option, but it is generally very restrictive so I advise against using it. This is the place in the documentation where these kinds of modifiable idioms are listed, but I agree that it is probably not clear enough. However, I don't consider this behaviour to be a caveat of this pragma, since it is consistent with what constructs the Perl language tags as modifiable. I'll think of something for the next release (no timeline implied).
Vincent
