Re^2: Dereference of undefined value OK under strictures?

> But this doesn't necessarily get to the l-value derivation of the issue

autovivification

A Graeco-Roman word meaning “to bring oneself to life”. 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.

Hence it's not undefined anymore when strict refs start checking.

Hth

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery
FootballPerl is like chess, only without the dice}

Comment on Re^2: Dereference of undefined value OK under strictures? Download Code

Replies are listed 'Best First'.
Re^3: Dereference of undefined value OK under strictures? by Don Coyote (Hermit) on Jun 30, 2019 at 12:51 UTC
Thank you, yes the autovivication entry is informative and useful. Rather I meant that for one or another reason the debugger steps over each line in both programs. Whereas I would like to explicitly step into the print function or subroutine call to expose for example, the lvalue determinations or aliasing operations. Although on a preliminary read-through of the docs that may be out of scope for the debugger.	[reply]
Re^4: Dereference of undefined value OK under strictures? by LanX (Saint) on Jun 30, 2019 at 13:07 UTC
The debugger is IMHO operating on a statement level. IOW the interpreter is calling the debugger routines for every semicolon (roughly). The OP tree has an entry for every statements start holding all meta inf like line numbers. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}	[reply]