[gdal-dev] Crash using mem raster on Windows

[Even Rouault]

On lundi 30 octobre 2017 18:08:52 CET Andrew Bell wrote:
> On Mon, Oct 30, 2017 at 4:36 PM, Even Rouault <even.rouault at spatialys.com>
> 
> wrote:
> > Andrew,
> > 
> > > I'm creating a memory raster using the following code:
> > > 
> > > [...]
> > > 
> > > I read the three bands in succession. This works fine on OSX/Linux, but
> > > 
> > > fails when attempting to read the second band on Windows. Any thoughts
> > > on
> > > 
> > > what might be the issue?
> > 
> > You need to use CPLPrintPointer() to format the pointer in a way
> > 
> > that will please the MEM driver
> > 
> > 
> > 
> > See https://github.com/OSGeo/gdal/blob/ddbf6d39aa4b005a77ca4f27c
> > 2d61a3214f336f8/gdal/alg/gdalcutline.cpp#L341
> 
> Thanks.
> 
> This doesn't seem robust.  It seems the code should be able to deal with
> something printed as a standard pointer.
> Is there some reason you know of why it simply doesn't scan the value?

Part of the answer is in this code snippet

{{{

int CPLPrintPointer( char *pszBuffer, void *pValue, int nMaxLen )
{
[...]
    char szTemp[64] = {};

    snprintf(szTemp, sizeof(szTemp), "%p", pValue);

    // On windows, and possibly some other platforms the sprintf("%p")
    // does not prefix things with 0x so it is hard to know later if the
    // value is hex encoded.  Fix this up here.

    if( !STARTS_WITH_CI(szTemp, "0x") )
        snprintf(szTemp, sizeof(szTemp), "0x%p", pValue);

    return CPLPrintString(pszBuffer, szTemp, nMaxLen);
}
}}}

The MEM buffer apparently supports passing the pointer as an hexadecimal value with must 
be prefix with 0x, or a decimal value.


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20171030/8552f289/attachment-0001.html>