On 12/22/2010 03:25 PM, Paul Eggert wrote:
> Thanks for the review and these are all good suggestions; I'll
> look into them.
Following up my own email -- I pushed this:
>From a80e645dd8bb8bc1bfdce5a2805cbfd37567 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 23 Dec 2010 23:32:55 -08
On 12/22/10 13:57, Bruno Haible wrote:
> But I would find it good if
>
> - you would modify m4/vsnprintf.m4 like m4/snprintf.m4 - otherwise the
> gnulib modules 'vsnprintf' and 'snprintf' are inconsistent.
>
> - the files doc/posix-functions/{snprintf,vsnprintf}.texi were be
> updated
On 12/22/10 13:47, Bruno Haible wrote:
> Why do people do this? It appears to be slower than just calling
> asprintf, because it has to parse the format string and produce
> the expansion twice.
In the case of coreutils, the snprintf (NULL, 0, ) is invoked
just once, to find out the size of th
Bruno Haible wrote:
> Eric Blake wrote:
>> one _very_ common use of snprintf is to call it with size 0 to see
>> how much to allocate, then allocate and call again.
>
> Why do people do this? It appears to be slower than just calling
> asprintf, because it has to parse the format string and produce
Hi Paul,
Eric Blake wrote:
> 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 snpri
Eric Blake wrote:
> one _very_ common use of snprintf is to call it with size 0 to see
> how much to allocate, then allocate and call again.
Why do people do this? It appears to be slower than just calling
asprintf, because it has to parse the format string and produce
the expansion twice.
==
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 li
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_
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 wit
Hi Paul,
> (gl_PRINTF_SIZES_C99, gl_PRINTF_DIRECTIVE_F, gl_SNPRINTF_RETVAL_C99):
> Fix typo in matching older versions of Solaris: "solaris2.10"
> is matched by the shell pattern "solaris2.[0-9]*". This matters
> only for guessing while cross-compiling.
There are more occurrences of this problem
This fixes a problem observed with the latest coreutils snapshot
that caused a test to fail on Solaris 8. src/csplit.c's call
snprintf (NULL, 0, format, UINT_MAX) returns -1 on Solaris 9 and
earlier, instead of returning the number of bytes that would have
been generated; this causes csplit to inc
11 matches
Mail list logo
