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

[Frank Warmerdam]

Eric Dönges wrote:
> 
> Am 01.11.2006 um 23:47 schrieb Ray Gardener:
> 
>> fprintf can be handled with:
>>
>>     int our_fprintf(our_file_t stream, const char* pszFormat, ...)
>>     {
>>         va_list argList;
>>         va_start(argList, pszFormat);
>>         int n;
>>         if(stream.small())
>>             n = vfprintf(stream.filep, pszFormat, argList);
>>         else
>>         {
>>             char sz[max_printf_len + 1]; // todo: unsafe
>>             n = vsprintf(sz, pszFormat, argList);
>>             large_file_write(stream.file, sz, n);
>>         }
>>         va_end(argList);
>>         return n;
>>     }
> 
> While this approach would certainly work, I think it would be better to 
> take an
> existing printf implementation (for instance from Cygnus newlib, located at
> http://sources.redhat.com/newlib) and adapt that to be exactly what GDAL 
> requires.
> This would avoid the fixed length temporary buffer (which is ugly !) and 
> allow us
> to have a locale-independent printf. I have adapted newlib's sprintf to 
> print directly
> into a ringbuffer (and removed floating point to conserve space for an 
> embedded
> project) before, so I know this is doable with moderate effort.
> 
> IMO, the best way to do this would be to add an fgetc-like function to 
> VSIVirtualHandle,
> and have a custom fprintf function that calls this fputc-like function 
> for every
> character to output.

Folks,

I would point out there is no need for any big complexity in this regard.
It is perfectly possible to implement printf style functionality on any
system with vsnprintf().  The CPLString::Printf() function demonstrates this.
Basically use vsnprintf(), and if the working buffer is too small, reset and
try again with a bigger buffer.

The discussions of a scanf() replacement are more significant.

I'd add there may still be a number of drivers that directly use a variety
of stdio functions with the FILE *'s returned by VSIFOpen().  A careful
review of existing usage would be required before it could be determined
whether this is still a problem, or if it will be hard to rectify.

I personally would feel much more comfortable to *not* try and change the
non-L VSI API, and stay focused on the VSI*L api.  It might be desirable
to review if some use of the small api can be replaced with the large but
this seems mostly orthagonal to the main discussion.

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