[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