Re: [PATCH] snprintf: port snprintf (NULL, 0, ...) to Solaris 8 and 9

[Paul Eggert]

On 12/21/2010 04:14 AM, Bruno Haible wrote:
> The module 'snprintf' was meant to merely
> allow uses such as
> 
>    char buf[80];
>    snprintf (buf, 80, some_wild_format, arguments);

But that is not good style, as it quietly truncates the output to 79
bytes.  GNU code shouldn't have arbitrary limits like that.

I checked today, and coreutils proper uses snprintf in three places:
once with (NULL, 0, ...), and twice with a fixed buffer as in the
above example.  The latter two uses are buggy.  Admittedly it's a
purely theoretical bug, as the bug comes into play only with integers
wider than 206 bits; but still, code shouldn't have arbitrary limits
like that.  I just published a fix
<http://lists.gnu.org/archive/html/bug-coreutils/2010-12/msg00081.html>;
once it's installed, (NULL, 0, ...) will be the only use case for
snprintf in coreutils.

This experience confirms my impression that snprintf (NULL, 0, ...)
should be supported just as well as snprintf (buf, sizeof buf, ...).
(Maybe even more so....)


On 12/21/2010 06:20 AM, Eric Blake wrote:

> Maybe a compromise is to change src/csplit to use vasprintf instead
> of snprintf,

I hadn't thought of that; but it is a bit of a hack, as it would
allocate and initialize and immediately free storage without actually
using it.  It would seem to run afoul of Jim's remark "Often, when I
use snprintf, it's because I want to avoid using as*printf."
<http://lists.gnu.org/archive/html/bug-gnulib/2010-11/msg00002.html>

I'm not completely opposed to this idea, but surely it's simpler to
assume that snprintf (NULL, 0, ...) works.