Hi Gary,
> > OK Guys, shall we dust this "snprintfv" thing off, polish a bit and
> > hand off to the interested gnulib folks? :) It'd be nice to have it
> > have first class support. Heck, I'd like to see some of the add-on
> > interfaces made more widely available anyway. :)
>
> That sounds like a splendid idea! I'll even have some time to spend
> on it starting next month.
This would be welcome. The presence in gnulib offers for your library:
- a tool for integration into other packages ("gnulib-tool --import
snprintfv")
and for standalone testing ("gnulib-tool --create-testdir snprintfv"),
- some people who proofread the code and do nitpicking, (*)
- more visibility; possibly other library codes will rely on it.
Now that gnulib supports subdirectories, you can even have all sources remain
in a lib/snprintfv/ directory.
snprintfv also has an interesting abstraction of "stream". This resembles
the output streams that I've been using in GNU gettext lately. (And it's a
pain to do this in C, rather than the ever-more-ugly C++.):
ostream
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
fd-ostream
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/fd-ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
file-ostream
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/file-ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
memory-ostream
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/memory-ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
term-ostream
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/term-ostream.oo.h?content-type=text%2Fplain&rev=1.2&root=gettext
iconv-ostream
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/iconv-ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
html-ostream
http://cvs.savannah.gnu.org/viewcvs/*checkout*/gettext/gnulib-local/lib/html-ostream.oo.h?content-type=text%2Fplain&rev=1.1&root=gettext
But I think the *printf replacements should continue to be based on the
vasnprintf code, because of object code size. On a Linux/x86 system:
$ size vasnprintf.o
text data bss dec hex filename
6669 0 0 6669 1a0d vasnprintf.o
$ ld -r -o snprintfv.o libsnprintfvc_la-*.o
$ size snprintfv.o
text data bss dec hex filename
17984 1020 416 19420 4bdc snprintfv.o
Not everyone want to spend 18 KB of object code in a facility that "nearly"
is contained in the standard libc. regex.o being even bigger is not much of
a justification because only ca. 20% of the programs need regex, whereas
100% need printf.
$ size regex.o [this one is compiled with -fPIC]
text data bss dec hex filename
62079 5964 0 68043 109cb regex.o
Bruno
(*) The snprintfv in smalltalk-2.3.2 has this compiler warning which really
looks like a bug:
printf.c: In function `stream_printfv':
printf.c:658: warning: assignment makes pointer from integer without a cast
