From e050cc0e6db974512bccc84746c68ba4ed3e4079 Mon Sep 17 00:00:00 2001 From: Nicholas Clark Date: Wed, 27 Feb 2008 11:48:38 +0000 Subject: [PATCH] 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 --- av.c | 13 +++++++++++++ 1 file changed, 13 insertions(+) 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; -- 2.7.4