bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

snprintfv (was: Re: Printf for gnulib?)


From: Bruno Haible
Subject: snprintfv (was: Re: Printf for gnulib?)
Date: Tue, 20 Feb 2007 02:49:59 +0100
User-agent: KMail/1.5.4

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]