This is a live mirror of the Perl 5 development currently hosted at https://github.com/perl/perl5
Comment on why I don't think changing Perl_safesysmalloc_size() in av.c
authorNicholas Clark <nick@ccl4.org>
Wed, 27 Feb 2008 11:48:38 +0000 (11:48 +0000)
committerNicholas Clark <nick@ccl4.org>
Wed, 27 Feb 2008 11:48:38 +0000 (11:48 +0000)
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

av.c

diff --git a/av.c b/av.c
index 4b3b08d..fa2be12 100644 (file)
--- 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;