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

[Andrew C Aitchison]

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) ?

Sorry to be confused.

-- 
Andrew C. Aitchison                      Kendal, UK
                    andrew at aitchison.me.uk