Remove usage of &PL_sv_undef in hashes and arrays

According to perlguts, &PL_sv_undef is not the right thing to use in
those cases because it doesn't behave the same way as an undef value via
Perl code.  Seems the intuitive way to deal with undef values is subtly
enough broken that it's hard to notice when misused.

The broken uses got inadvertently introduced in commit
87bb2ade2ce646083f39d5ab3e3307490211ad04 by Alexey Klyukin, Alex
Hunsaker and myself on 2011-02-17; no backpatch is necessary.

Per testing report from Greg Mullane.

Author: Alex Hunsaker

diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index d69d232..f2e8ad2 100644 (file)
--- a/src/pl/plperl/plperl.c
+++ b/src/pl/plperl/plperl.c
@@ -1357,7 +1357,13 @@ make_array_ref(plperl_array_info *info, int first, int last)
        for (i = first; i < last; i++)
        {
                if (info->nulls[i])
-                       av_push(result, &PL_sv_undef);
+               {
+                       /*
+                        * We can't use &PL_sv_undef here.  See "AVs, HVs and undefined
+                        * values" in perlguts.
+                        */
+                       av_push(result, newSV(0));
+               }
                else
                {
                        Datum           itemvalue = info->elements[i];
@@ -2639,8 +2645,12 @@ plperl_hash_from_tuple(HeapTuple tuple, TupleDesc tupdesc)
 
                if (isnull)
                {
-                       /* Store (attname => undef) and move on. */
-                       hv_store_string(hv, attname, &PL_sv_undef);
+                       /*
+                        * Store (attname => undef) and move on.  Note we can't use
+                        * &PL_sv_undef here; see "AVs, HVs and undefined values" in
+                        * perlguts for an explanation.
+                        */
+                       hv_store_string(hv, attname, newSV(0));
                        continue;
                }