[Top][All Lists]

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

Re: Printf for gnulib?

From: Bruce Korb
Subject: Re: Printf for gnulib?
Date: Mon, 19 Feb 2007 19:40:44 -0800
User-agent: Thunderbird (X11/20060911)

Bruno Haible wrote:

> I agree that gnulib should offer POSIX compliant *printf functions. However,
> since just having the function _at_all_, without requiring full POSIX,
> has been good enough for many packages, and vasnprintf.c is a big chunk of
> code that many people probably don't want to see added to every executable
> unless absolutely necessary, I would like that gnulib proposes two offers:
>   (A) The "minimal" offer: just ensure that the function exists.
>       Modules: snprintf, vsnprintf,
>                asprintf, vasprintf.
>   (B) Full POSIX offer: override the system functions if they are not POSIX
>       compliant.
>       Modules: snprintf-posix, vsnprintf-posix,
>                sprintf-posix, vsprintf-posix,
>                fprintf-posix, vfprintf-posix,
>                printf-posix, vprintf-posix,
>                asprintf-posix, vasprintf-posix.
> This dual offer is similar to what we do with "fnmatch-posix" and
> "fnmatch-gnu".
> I include [v]asprintf in this list, because although it's not a POSIX 
> function,
> NetBSD has asprintf but it does not support POSIX format strings ( 2) 
> missing).
> With this offer, everyone should be served, I think?

libsnprintfv has argument ordering also.  It really has absolutely everything.
If you can define a good way of expressing, "these are the features I need
from the *printf* functions", then you can use that information to determine
if the native implementation covers it.  It all sounds pretty messy to me.
Especially since it is hard to remember what printf features I use in my code.
Now maybe I'm not using "%zd" in my code, but if I add it tomorrow, just
how in heck am I to remember to fix up my configure testing?  It ain't worth
the "savings".

For my own purposes, I find it easier to not worry over whether or not the
native functionality is sufficient.  Then again, I don't care a whit about
code size.  :)

Whatever.  Cheers - Bruce

reply via email to

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