Re: Inconsistency of 'Use of uninitialized value in scalar assignment' warning

To avoid autovivification of hash elements that might only end up getting used in rvalue context, when you call a function with a hash element as an arg, e.g. foo($hash{$key}), perl invokes a special mechanism.

When perl initially tries to retrieve the hash element before calling the function, if the element doesnt exist, then rather than autovivifying and creating a new null element, it creates a temporary proxy object which has the hash and the key attached to it. When at this point the key is being evaluated, this triggers the first uninit warning. Later inside the function, the value of the proxy object is evaluated during the assignment, which triggers a second (redundant) uninit warning as the undef key is used to retrieve the hash element.

Dave.

Comment on Re: Inconsistency of 'Use of uninitialized value in scalar assignment' warning Download Code

Replies are listed 'Best First'.
Re^2: Inconsistency of 'Use of uninitialized value in scalar assignment' warning by ccn (Vicar) on Dec 26, 2013 at 13:11 UTC
The difference between two `foo` call cases is evaluation of undefined `$baz` variable. Isn't it? So we got first warning. But why we got the second warning? In both cases proxy object must be created and be evaluated during the assignment the same way, and must produce the same warnings.	[reply] [d/l] [select]
Re^3: Inconsistency of 'Use of uninitialized value in scalar assignment' warning by dave_the_m (Monsignor) on Dec 26, 2013 at 18:54 UTC
I think people are still thinking that the second undef warning is due the hash value not existing; its not. Both warnings are being generated by trying to evaluate the key. In the first foo() call in the OP, the key isn't undef, so it doesn't generate any warnings. Dave.	[reply]