Re: snprintfv

[Bruce Korb]

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