AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2004.07.08 10:03 "[Tiff] Is GDAL "errno-safe" ?", by Julien Demaria
2004.07.08 13:25 "[Tiff] Re: [Gdal-dev] Fwd: Is GDAL "errno-safe" ?", by Frank Warmerdam

2004.07.08 13:25 "[Tiff] Re: [Gdal-dev] Fwd: Is GDAL "errno-safe" ?", by Frank Warmerdam

Julien Demaria wrote:
> I forward my message to gdal-dev@remotesensing.org because
> gdal-dev@xserve.flids.co seams to failed...

Julien,

I encourage use of gdal-dev@remotesensing.org. The other address is gdal-dev@xserve.flids.com (note them "m" in com).

I maintain an application which used libTIFF and I'm "upgrading" to GDAL. I want to use GDAL directly for all drivers except for TIFF files to keep our existent optimized code for TIFF files (the major argument is that with GDAL we must always read RGB contigu TIFF in 3 separate bands and this is slower than using directly the contigu data, above all you want finally rewrite the data in a contigu TIFF, isn't it ?)

There is a GDAL approach to reading interleaved data in one pass by using the GDALDataset::RasterIO() call. However, no support has yet been introduced into the GeoTIFF driver to do this efficiently. I should really look into this at some point.

So for TIFF files I try to use tiff functions embedded in GDAL shared library ; and it seams to work very well.

All works well except when I try to open a TIFF file in write mode, because my application handle a errno 9 ("Bad file descriptor") after the XTIFFOpen call:

I call XTIFFOpen in write mode =>... TIFFClientOpen and in TIFFClientOpen fuction at line 278 in tif_open.c, I understand that we test if we can read the file (even for write mode) with ReadOK function which finally calls fread in cpl_vsisimple.cpp This fread call set errno to 9 ("Bad file descriptor"), but this is a "normal" case handled by TIFFClientOpen.

The problem is that errno is set to 9, but there isn't any "real error".

Maybe it is possible to modify TIFFClientOpen to be "errno-safe"?

In general libtiff and GDAL do not try to clear errno after recoverable errors. I gather you want it too so that you can use errno for post call decisions, is that right? I am not at all convinced that it is wise of you to try and do this precisely because neither library attempts to maintain any errno state after calls.

I am hesitant to start trying to maintain "clean" errno semantics at this late date. It seems it would be quite difficult (especially for GDAL) to ensure that errno is always explicitly cleared when appropriate. This is really not the sort of constratain that should be engineered in "after the fact".

Best regards,

---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent