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.
