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

Eric Dönges eric.doenges at gmx.net
Thu Nov 2 03:07:50 EST 2006


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. While this does add the overhead of a function  
call for each
character output, on Unix system at least this shouldn't really be  
all that bad because
stdio is buffered, and the really expensive part of I/O is only  
triggered once the
system has to actually write the buffer to disk. However, I don't  
know anything about
Windows programming, so I can't comment on if it's feasible to do  
something like this
for the Windows implementation of VSIVirtualHandle. It would of  
course also be possible
to have separate printf functions for each of the concrete  
implementations of
VSIVirtualHandle (memory, Unix stdio, and Windows), but that would  
duplicate a lot of
code, and risk having the different printf functions behave slightly  
different from each
other.

> fscanf is admittedly non-trivial but there's open source to the  
> rescue.
> If you grab, e.g., http://gentoo.osuosl.org/distfiles/avr- 
> libc-1.2.6.tar.bz2
>
> it has open source implementations of CRT that you can borrow from.  
> Their licence states:
> "The contents of avr-libc are licensed with a Modified BSD License.
> All of this is supposed to be Free Software, Open Source, DFSG-free,
> GPL-compatible, and OK to use in both free and proprietary  
> applications."

Personally, I'm partial to newlib (which also has a BSD-like licence  
- actually, the
printf code itself is taken from BSD), because I've been using that  
in my day jobs for
the last 9 years or so.

With kind regards,
Eric



More information about the Gdal-dev mailing list