[Gdal-dev] Fwd: Is GDAL "errno-safe" ?

Julien Demaria dem at acri-st.fr
Thu Jul 8 06:08:51 EDT 2004


I forward my message to gdal-dev at remotesensing.org because 
gdal-dev at xserve.flids.co seams to failed...

>Date: Thu, 08 Jul 2004 12:03:39 +0200
>To: gdal-dev at xserve.flids.co
>From: Julien Demaria <dem at acri-st.fr>
>Subject: Is GDAL "errno-safe" ?
>Cc: tiff at remotesensing.org
>
>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 ?)
>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" ?
>
>I've also noted in the past a similar problem also in TIFFClientOpen at 
>line 365 when try to use memory-mapped file : if the test of mmap fails, 
>errno is set to ENOMEM.
>
>I think also GDALOpen isn't "errno-safe" when it try to open the file with 
>each driver ; I've a least one example which set errno to 2 I believe... 
>If you want I can search the driver in cause...
>
>Best Regards,
>
>Julien




More information about the Gdal-dev mailing list