LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
July 2004
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2004.07.08 13:25 "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).
> > Hi,
> >
> > 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