[Gdal-dev] RFC 7: API Change for the VSIxxxL family of
eric.doenges at gmx.net
Tue Oct 31 05:16:16 EST 2006
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
> (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
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
> 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
> 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
errors in C and C++. However, this way we would loose the better type
checking by the
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++
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,
More information about the Gdal-dev