Why does $foo->{bar} autovivify but %$foo doesn’t?

Note   Code added to the question demostrates why autovivification doesn’t happen.

Short   Your sub takes a list (hash) which has an anonymous array as an element – and %$headers is buried in that array. It is the anon array
that is the scalar aliased to, thus there is no requirement for %$headers to be modifiable. Thus no autovivification happens, and you get the fatal runtime error described below, as dereferencing is attempted on an undefined reference.


A %$ref autovivifies when used in lvalue context. This may happen in a sub call, see below.

The error you show is due to the use of an undefined reference. For example, the statement

my %hash = %{ $ref };

attempts to copy a hash from the memory location stored in $ref and assign it to %hash. The symbol %hash is created at compile time, but if no hash is found at $ref or if there is nothing in $ref, we get an error. No autovivification happens here. With use strict in effect

perl -wE'use strict; my $h; my %h = %$h; say $h'

this throws the fatal runtime error

Can't use an undefined value as a HASH reference at -e line 1.

When eval-ed to survive that

perl -wE'use strict; my $h; my %h = eval { %$h }; say $h; say "hi"'

it prints a warning about “uninitialized value“, an empty line, and then hi. No hash.

However, when used as an argument in a subroutine call it autovivifies

perl -wE'use strict; sub tt { 1 }; my $h; tt( %$h ); say $h'

as this prints the line HASH(0x257cd48), without warnings or errors.

The autovivification happens when a dereferenced object is used in lvalue context, which means that it needs to be modifiable. In a subroutine call the reason for this is that arguments to a function are aliased in @_ so it must be possible to modify them. The same aliasing need makes it happen in a foreach loop, while keys resets the hash iterator. See this post and this post and this post.

Thanks to ThisSuitIsBlackNot for explanation and links.

In your case the %$ref is passed as an element of an anonymous array, and is thus not aliased (the arrayref itself is). So autovivication does not kick in and you get that error.


On autovivification from perlglossary

In Perl, storage locations (lvalues) spontaneously generate themselves as needed, including the creation of any hard reference values to point to the next level of storage. The assignment $a[5][5][5][5][5] = "quintet" potentially creates five scalar storage locations, plus four references (in the first four scalar locations) pointing to four new anonymous arrays (to hold the last four scalar locations). But the point of autovivification is that you don’t have to worry about it.

Also see, for example, an article from Effective Perler

Leave a Comment