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@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
