Change 33383 by [EMAIL PROTECTED] on 2008/02/27 11:48:38
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? :-)]
Affected files ...
... //depot/perl/av.c#130 edit
Differences ...
==== //depot/perl/av.c#130 (text) ====
Index: perl/av.c
--- perl/av.c#129~33379~ 2008-02-26 15:22:30.000000000 -0800
+++ perl/av.c 2008-02-27 03:48:38.000000000 -0800
@@ -118,6 +118,19 @@
#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;
End of Patch.
