[gdal-dev] New RFC : RFC 19 - Safer memory allocation in GDAL

Even Rouault even.rouault at mines-paris.org
Sun Dec 30 05:39:38 EST 2007


Frank,

thank you for the feedback. I've taken your remarks into account and revised 
the RFC accordingly.

A question : while looking at CPLMalloc implementation, I've noticed there's a 
call to CPLVerifyConfiguration. Is there a particular reason for this 
function to be called here / are there situations where the checks fail ... ? 
CPLMalloc also seems to be the unique function to use CPLVerifyConfiguration. 
I'm just curious why it is needed there and not at other places. We could 
imagine that these checks could be done once, early at GDAL or OGR 
initialization, for example in GDALAllRegister or OGRRegisterAll.
The practical question is : do I need to call CPLVerifyConfiguration in 
CPLSafeMallocX ?

Best regards.

Le Sunday 30 December 2007 02:04:45 Frank Warmerdam, vous avez écrit :
> Even Rouault wrote:
> > Hi all,
> >
> > I've written a new RFC
> > (http://trac.osgeo.org/gdal/wiki/rfc19_safememalloc) that is a proposal
> > to avoid under memory allocations due to multiplication overflows.
> >
> > This proposal is opened to discussion.
>
> Even,
>
> A bit of preliminary feedback:
>
>   o I'd like to see the CPL prefix used instead of VSI.  VSI is supposed
>     to stand for "Virtual Systems Interface" and is intended to wrap lower
>     level system stuff, while CPL is used as the prefix for higher level
>     convenience stuff.
>
>   o I'd like to see a CPLSafeMalloc2(x,y) and CPLSafeMalloc3(x,y,z) that
>     would use the Mult functions, and if an overflow occurs issue an error
>     and return NULL.  The caller should be able to just check for a NULL
>     result and return if NULL knowing that a CPLError had already been
>     issued.  I think this would make use of the 'overflow safe allocation'
>     easier (and less verbose) to deploy in many places.
>
> I'm generally supportive of this initiative though it isn't a problem
> I've found a great issue myself.
>
> Best regards,




More information about the gdal-dev mailing list