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

[Eric Blake]

On 12/21/2010 05:14 AM, Bruno Haible wrote:
> Hi Paul,
> 
>> +       * m4/printf.m4 (gl_SNPRINTF_RETVAL_C99): Also check for
>> +       snprintf (NULL, 0, ...) and (for good measure) snprintf (buf, 0, 
>> ...).
> 
> Thanks. Yet another *printf portability problem...
> 
>> * m4/snprintf.m4 (gl_FUNC_SNPRINTF): Also check gl_SNPRINTF_RETVAL_C99.
> 
> I disagree with this change: The module 'snprintf' was meant to merely
> allow uses such as
> 
>    char buf[80];
>    snprintf (buf, 80, some_wild_format, arguments);
> 
> If a user wants more from snprintf(), he needs to require 'snprintf-posix'.

I agree that requiring snprintf-posix for full use cases makes sense,
but one _very_ common use of snprintf is to call it with size 0 to see
how much to allocate, then allocate and call again.  Among all the
portability problems fixed by snprintf-posix, the return value for size
0 buffer makes the most sense to me to promote to plain snprintf.

> 
> The platforms on which this change introduces an snprintf() wrapper
> although snprintf already exists are: Solaris 2.6..9, AIX 5.1, HP-UX 11,
> IRIX 6.5, OSF/1 5.1.
> 
> coreutils already uses 'vasprintf-posix' and 'xprintf-posix'. It would
> not bring in much more code to require also 'snprintf-posix'.

Maybe not much code added to the tarball, but very few of the coreutils
actually use vasprintf and xprintf, so it will enlarge quite a few of
the binaries to start replacing snprintf.  Maybe a compromise is to
change src/csplit to use vasprintf instead of snprintf, and not trigger
the snprintf(NULL,0) bug in the first place since we already have the
vasprintf wrapper.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature