Opened 16 years ago
Closed 16 years ago
#2398 closed defect (fixed)
tiff_ovr_3 fails when creating tiffs with non native endianness
Reported by: | Even Rouault | Owned by: | Even Rouault |
---|---|---|---|
Priority: | normal | Milestone: | 1.6.0 |
Component: | GDAL_Raster | Version: | unspecified |
Severity: | normal | Keywords: | gtiff endianness |
Cc: | warmerdam |
Description
I've added a new creation option to the GTiff driver that enables to set the endianness of the created file. This can also be set with the GDAL_TIFF_ENDIANNESS environement variable. See r14591
I've run the entire autotest suite with GDAL_TIFF_ENDIANNESS=INVERTED and observed that tiff_ovr_3 fails. (I've modified tiff_ovr.py to run with native and inverted endianness so we can exhibit this bug. See r14592)
Change History (4)
comment:1 by , 16 years ago
Cc: | added |
---|---|
Owner: | changed from | to
comment:2 by , 16 years ago
comment:3 by , 16 years ago
"Replace tmsize_t by int in previous commit as tmsize_t is not defined in old libtiff headers" in r14597
comment:4 by , 16 years ago
Milestone: | → 1.6.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
The fix in trunk was the opportunity to reorganize strip&tile writing, and then it is maybe too intrusive for backporting to 1.5. Closing then.
The reason for the failure was that TIFFWriteEncodedStrip/TIFFWriteEncodedTile can modify the buffer that is passed to them if the endianness of the file is not the native endianness. The solution was to copy the buffer in a temporary buffer before passing it to those functions.
Fixed in trunk in r14596