On Mon, 18 Dec 2023, Even Rouault wrote:
Le 18/12/2023 à 21:15, Andrew C Aitchison a écrit :
On Mon, 18 Dec 2023, Even Rouault via gdal-dev wrote:
Le 18/12/2023 à 16:18, Andrew C Aitchison via gdal-dev a écrit :
On Mon, 18 Dec 2023, Even Rouault via gdal-dev wrote:
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
Did you mean to say
Note that even with eRWFlag==GF_Write, the content of the buffer
might be temporarily modified during the execution of this method
(and eventually restored back to its original content), so it is not
safe to use a buffer stored in a read-only section of the calling
program.
Yes I meant that. I've less evidence in the RasterIO(GF_Write, ...) case
than in the WriteBlock() case, but without checking all drivers, it is
more prudent to assume that the buffer might be touched during
RasterIO(GF_Write) by some drivers.
In that case I don't understand
Note that even with eRWFlag==GF_Write...
It suggests to me that the buffer may be modified for eRWFlag==GF_Write
*as well as* for eRWFlag==GF_Read (which implies that it is *more* likely
to happen for GF_Read) ?
Ah, perhaps non-idiomatic wording from mine. I struggle to make that clearer:
if you've better wording to suggest, that's welcome
Ah. I had misunderstood.
I thought we were reading to or writing from *the buffer* not the raster.
The text is fine.
--
Andrew C. Aitchison Kendal, UK
and...@aitchison.me.uk
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev