[Gdal-dev] RFC 7: API Change for the VSIxxxL
family of file functions
warmerdam at pobox.com
Thu Nov 2 10:52:32 EST 2006
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;
>> n = vfprintf(stream.filep, pszFormat, argList);
>> char sz[max_printf_len + 1]; // todo: unsafe
>> n = vsprintf(sz, pszFormat, argList);
>> large_file_write(stream.file, sz, n);
>> 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
> 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
> 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
> and have a custom fprintf function that calls this fputc-like function
> for every
> character to output.
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.
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
More information about the Gdal-dev