Using $h{x} is sufficient to autovifiy a key/value pair if there is no key/value pair for the key 'x' in the hash %h.

In the first case you give, the key 'x' is added to the hash (the $h{x} bit does that) with the value undef. The %{...} then tries to dereference the undef and generates the error that you see.

The second case is equivalent to:

my $ref = undef;
keys %{$ref}; # or: keys %$ref;
[download]

which, somewhat surprisingly, is fine and is about the same as asking for the keys of an empty hash. I guess this is an element of DWIM coming into play - if you ask for the keys of a hash reference that you haven't gotten around to assigning any key/value pairs to yet, then a list of not keys (and no errors generated) is a pretty reasonable thing to do.

But using $h{x} will not add an undef value into $h{x}. It just returns an undef value since $h{x} doesn't exist. I still don't see what magic keys() is using to get around the syntax error message.

A hash can't have a key without a value (that's why I refer to key/value pairs). If you reference $h{x} in some fashion (except as a target for exists) then a x/undef pair is created (autovivified) for %h if it didn't exist already. The undef returned by $h{x} is the value associated with the key 'x'.

"Adding" an undef value to %h when $h{x} is used is exactly what autovivification does.

---

Perl is environmentally friendly - it saves trees