develooper Front page | perl.perl5.changes | Postings from April 2008

Change 33746: revert the integration of 32815 "We can now sv_upgrade(sv, SVt_PVHV)"

From:
Dave Mitchell
Date:
April 25, 2008 08:00
Subject:
Change 33746: revert the integration of 32815 "We can now sv_upgrade(sv, SVt_PVHV)"
Change 33746 by davem@davem-pigeon on 2008/04/25 14:45:48

	revert the integration of 32815 "We can now sv_upgrade(sv, SVt_PVHV)"

Affected files ...

... //depot/maint-5.10/perl/mro.c#4 edit

Differences ...

==== //depot/maint-5.10/perl/mro.c#4 (text) ====
Index: perl/mro.c
--- perl/mro.c#3~33742~	2008-04-24 19:21:31.000000000 -0700
+++ perl/mro.c	2008-04-25 07:45:48.000000000 -0700
@@ -554,12 +554,19 @@
         HE *he = hv_fetch_ent(PL_isarev, sv, TRUE, 0);
 
 	/* That fetch should not fail.  But if it had to create a new SV for
-	   us, then will need to upgrade it to an HV (which sv_upgrade() can
-	   now do for us. */
+	   us, then we can detect it, because it will not be the correct type.
+	   Probably faster and cleaner for us to free that scalar [very little
+	   code actually executed to free it] and create a new HV than to
+	   copy&paste [SIN!] the code from newHV() to allow us to upgrade the
+	   new SV from SVt_NULL.  */
 
         mroisarev = (HV*)HeVAL(he);
 
-	SvUPGRADE((SV*)mroisarev, SVt_PVHV);
+	if(SvTYPE(mroisarev) != SVt_PVHV) {
+	    SvREFCNT_dec(mroisarev);
+	    mroisarev = newHV();
+	    HeVAL(he) = (SV *)mroisarev;
+        }
 
 	/* This hash only ever contains PL_sv_yes. Storing it over itself is
 	   almost as cheap as calling hv_exists, so on aggregate we expect to
End of Patch.



Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About