Don't autovivify array and hash elements in sub parameters

On Thu, 06 Mar 1997 10:02:33 PST, Larry Wall wrote:
>: =head2 Why does passing a subroutine an undefined element in a hash create it?
>:
>: If you say something like:
>:
>:     somefunc($hash{"nonesuch key here"});
>:
>: Then that element "autovivifies"; that is, it springs into existence
>: whether you store something there or not.  That's because functions
>: get scalars passed in by reference.  If somefunc() modifies C<$_[0]>,
>: it has to be ready to write it back into the caller's version.
>
>I still think this behavior is bogus.  By default, it should simply be
>an error to pass an undefined value to a routine that wants to modify
>it.  (We can maybe modify that in the future with prototypes.)
>
>: =for p5p is this still true?
>
>Yes, unfortunately.  Is my editorial opinion leaking through here?  :-)

I hope you considered my one-line patch to revert this behavior to that of
perl5.001 (and perl4).  I still think we'd be doing a service to include
this patch in 5.004 (and remove that section from the FAQ and the docs).

One may still modify real scalars via $_[0] with the patch, so it has
little potential to cause breakage.

p5p-msgid: 199703061912.OAA20606@aatma.engin.umich.edu

diff --git a/op.c b/op.c
index f27aa94..f3e39fb 100644 (file)
--- a/op.c
+++ b/op.c
@@ -4399,7 +4399,6 @@ OP *op;
        }
        else
            list(o);
-       mod(o, OP_ENTERSUB);
        prev = o;
        o = o->op_sibling;
     }