From: Nicholas Clark <nick@ccl4.org>
Date: Wed, 27 Feb 2008 11:48:38 +0000 (+0000)
Subject: Comment on why I don't think changing Perl_safesysmalloc_size() in av.c
X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=e050cc0e6db974512bccc84746c68ba4ed3e4079;p=p5sagit%2Fp5-mst-13.2.git

Comment on why I don't think changing Perl_safesysmalloc_size() in av.c
analagous to the change in sv.c is a good idea.	[It's not a language
design issue, so sadly I can't get a talk out of it. Or is that
fortunately? :-)]

p4raw-id: //depot/perl@33383
---

diff --git a/av.c b/av.c
index 4b3b08d..fa2be12 100644
--- a/av.c
+++ b/av.c
@@ -118,6 +118,19 @@ Perl_av_extend(pTHX_ AV *av, I32 key)
 #endif
 
 #ifdef Perl_safesysmalloc_size
+		/* Whilst it would be quite possible to move this logic around
+		   (as I did in the SV code), so as to set AvMAX(av) early,
+		   based on calling Perl_safesysmalloc_size() immediately after
+		   allocation, I'm not convinced that it is a great idea here.
+		   In an array we have to loop round setting everything to
+		   &PL_sv_undef, which means writing to memory, potentially lots
+		   of it, whereas for the SV buffer case we don't touch the
+		   "bonus" memory. So there there is no cost in telling the
+		   world about it, whereas here we have to do work before we can
+		   tell the world about it, and that work involves writing to
+		   memory that might never be read. So, I feel, better to keep
+		   the current lazy system of only writing to it if our caller
+		   has a need for more space. NWC  */
 		newmax = Perl_safesysmalloc_size((void*)AvALLOC(av)) /
 		    sizeof(SV*) - 1;