From: Gurusamy Sarathy <gsar@engin.umich.edu>
Date: Thu, 6 Mar 1997 19:12:09 +0000 (-0500)
Subject: Don't autovivify array and hash elements in sub parameters
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=0ffc6623ceb5acc7b954e8cdbaeb8ba319474d7b;p=p5sagit%2Fp5-mst-13.2.git

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
--- 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;
     }