Hi Arjen, José, and Maurice: (I am explicitly addressing Maurice as well since he may know the origin of the free_mem macro that I discuss below.)
First, I would like to thank José for his plfill and plgradient patches, and I am glad Arjen is going to apply them. That will make my further changes to plfill and plgradient (many months down the road) easier. Further comments below. On 2010-12-23 14:42+0100 Arjen Markus wrote: > Hi José, > > stopping the program in such dramatic circumstances may be the > best option. We have had some discussion recently about the > best policy, but I am what consensus was reached. I suggest > right now we go ahead with your patch and see what corrections > are needed later (running out of memory ought to be an unlikely > event ...). > > Regards, > José and Arjen have been discussing two separate situations which we should clearly distinguish. 1. What to do right after malloc fails. In this case, I think we should consistently plexit (which calls exit after a error message) as implied by what Arjen said above. malloc failing is an extremely rare error corresponding to out-of-memory when all sorts of bad things are happening in any case. So in my view the arguments expressed on this list before against using plexit (since it not only takes down PLplot but also any interactive environment such as Python or octave that is trying to use it) don't apply that strongly when malloc is failing. 2. How to free the memory after it has been used if the pointer is NULL. This is a non-issue if 1. is dealt with using plexit. However, it is interesting to discuss it anyway. In this case I _think_ José is right and a simple free should do. B&K second edition p 252 says the same as the man page José has been quoting: "does nothing if p is NULL". So since B&K is the C bible, that should be it. Maurice, do you know the origins of the free_mem macro in include/plplotP.h? That does deal with the NULL pointer case for frees, but it also sets the pointer to NULL after every free so I think this macro was meant to be used to guard against double frees of the same memory. OTOH, another interpretation is the author of that macro had run into a badly implemented free implementation that didn't deal properly with a NULL pointer. I would like to get rid of free_mem in the long term if either interpretation is correct. First, I would hope our code is smart enough these days not to attempt double frees. Second, I hope modern implementations of free pay attention to the C standards so they deal properly with the NULL pointer case. In any case, this question should be moot if we uniformly plexit whenever malloc fails. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
