[gdal-dev] Under what (if any) conditions would GDALWriteBlock modify data buffer?

[Even Rouault]

Hi,

interesting question. No easy answer as it is highly driver dependent. I 
believe that all drivers make sure that the content of the buffer before 
and after the call is the same, but some drivers might temporarily 
modify it, to do byte swapping. For example the HFA driver does that 
when run on big-endian hosts for non-Byte data type. I wouldn't exclude 
that for formats with MSB-byte ordering, a similar situation would 
happen for little endian hosts. So it is definitely not safe to use 
WriteBlock() with a buffer that would come from a read-only section of 
the calling program. Doc updated to reflect that in 
https://github.com/OSGeo/gdal/commit/ea321723dfc69ef3a422b1e3fe4dc9ee0832861d

Even

Le 17/12/2023 à 23:09, Fitch, Simeon via gdal-dev a écrit :
> The last argument to function `CPLErr GDALWriteBlock(GDALRasterBandH, 
> int, int, void*)`, pointing to the block array, is not `const`.  I 
> can't find anything in the documentation discussing ownership, etc. 
> but need to know what kind of invariants can be assumed here.
>
> Are there (driver dependent?) circumstances where `GDALWriteBlock` 
> will mutate the given array, or can callers assume it's effectively 
> `const void*`?
>
> Thanks,
>
> Simeon
>
> The content of this email is intended for the person or entity to 
> which it is addressed only. This email may contain confidential 
> information. If you are not the person to whom this message is 
> addressed, be aware that any use, reproduction, or distribution of 
> this message is strictly prohibited. If you received this in error, 
> please contact the sender and immediately delete this email and any 
> attachments.
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20231218/f777b58c/attachment.htm>