Bruno Haible wrote:
> 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.
That's what I was thinking, too.
> 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:
With typical new systems using 1GB ram and 150GB disk,
we're talking 1/100000 of the RAM and less than ten millionths
of one percent of disk space. Just for a work station. Convenience
is more important, but pushing on the issue isn't worth it either.
> 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.
I'm sure some people care. I used to. I surely don't any more.
==========
An amusing adjunct project for gnulib would be a gnulib wrapper.
It figures out what backfills are needed for a particular platform,
and constructs a header file and shared library. Very similar to
a proposal I wrote for an autotool bake-off contest some half dozen
years ago. Only with the gnulib project available now, there'd
be little work left to do .... :-D
With that, a project merely has to test for the existence of the
backfill library and bypass 99.99% of the configure script. Whew!!
Not today tho. Just an amusing thought.
Cheers - Bruce
