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

[Frank Warmerdam]

Eric Dönges wrote:
> 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).

Eric,

VSIFOpenL() is not an across the board replacement for VSIFOpen().
The non-L version of the functions continue to exist because
some drivers use stdio functions that are not implemented for in
the "L" api, such as VSIFGets().  In some cases driver code directly
calls stdio functions using the FILE *.

Nevertheless, most of the "non-L" drivers using the raw dataset
classes could likely be upgraded to use the "L" api.

>> 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.

Agreed.  One approach might be to make VSILFILE* a void pointer for now
with the intention of making it something else that would trigger type
checking failures later - perhaps when we switch to GDAL 2.0 and are
willing to sacrifice some backwards compatibility anyways.

In the meantime applications can upgrade to the new mechanisms without
too much disruption.

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

This is of course unknowable.  I have delivered some applications to
clients that will stop building without changes, but not too many.  But
one can never know how much of this sort of thing is out there.

Use and manipulation of the "L" api is the preferred way of handling
files read from memory buffers.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org