[Gdal-dev] RFC 7: API Change for the VSIxxxL family of file functions

[Eric Dönges]

Am 30.10.2006 um 20:43 schrieb Frank Warmerdam:

> There are some classes, like the Raw dataset classes that use FILE *
> and a boolean to indicate that the FILE * should either be interpreted
> as a "large file API" pointer (ie. VSIFOpenL()) or a small file api  
> pointer
> (ie. VSIFOpen()).  So there will be a few changes at the api and class
> contents level (beyond just the type change).

Good point; I wasn't aware that there are drivers that use both  
VSIFOpen and VSIFOpenL
at the same time. Perhaps this would be a good time to move those  
drivers over
to using VSIFOpenL exclusively ? (I'm assuming that VSIFOpenL and  
friends can serve as
a complete replacement for VSIFOpen).

> Also, this change will require a code change in any application (or  
> private
> driver) code that uses the large file API.  That is, we are making a
> backwards incompatible source level change in the C API (at the CPL  
> level).
> I am generally very nervous about doing this.

The only possible way to avoid this problem would be to typedef  
VSILFILE* to a void
pointer since any pointer can be converted to a void pointer without  
warnings or
errors in C and C++. However, this way we would loose the better type  
checking by the
compiler.

So, IMO the question to answer here is how much code outside of gdal/ 
ogr itself uses
the VSIFxxxL family of functions ?

> At the very least, I think backward compatibility issues need to be
> addressed in the RFC.

Ok, so I'll add the following section:

-- snip --

Backwards compatibility issues

Any code that uses the VSIFxxxL family of functions must be changed  
to use VSILFILE
instead of FILE, since unchanged code will fail to compile with C++  
compilers and
generate warnings with (most) C compilers. However, binary  
compatibility when using gdal
as a shared library should not be affected, since the VSIFxxxL family  
of functions are C
wrapper functions that are not subject to C++ type mangling rules,  
and the actual
implementation of the functions remains unchanged.

-- snip --

With kind regards,
Eric