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 ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
