Re: glibc's snprintf can fail with ENOMEM: replacement needed

[Jim Meyering]

Bruno Haible <address@hidden> wrote:
> Jim Meyering wrote:
>> FYI, I've just reported the problem:
>>
>>     http://bugzilla.redhat.com/441945
>>     http://thread.gmane.org/gmane.comp.lib.glibc.alpha/13288
>>
>> Quick summary: given a small buffer, say "char b[10];" with the latest
>> upstream glibc, snprintf (b, sizeof b, fmt, 0) can fail, returning -1
>> with ENOMEM.
>
> The possibility of this happening was already mentioned by Andreas Schwab
> ([1],[2]):
>
>   "A failure from printf does not necessarily mean an output failure.  It
>    can also be ENOMEM or EILSEQ, which are unrelated to output."
>
>   "There are two failure modes for ENOMEM:
>      - inability to allocate stdio buffers
>      - inability to allocate conversion buffers

Not quite.  With snprintf, "stdio buffers" should be irrelevant.
The ENOMEM problems are due to the glibc implementation, and
not to any inherent requirements.  EILSEQ is inevitable, so
I don't consider it a problem, here.  Gnulib should do better.

Maybe you all realized it months ago but just didn't say anything,
but it certainly didn't click with me that snprintf can fail in this
surprising manner (i.e., with ENOMEM, even when it has a large enough
buffer).

> There are two cases of conversion buffers:
>   1) for float to decimal conversion, think of snprintf (NULL, "%Le", x)
>      or snprintf (NULL, "%Lf", x)
>   2) for wchar_t* to char* conversion, think of snprintf (NULL, "%ls", s).
> and two other cases of memory allocation:
>   3) for integer to decimal conversion,
>   4) for padding.
>
> At least in the first case, I don't see how the number of output bytes could
> be determined without doing the actual conversion.

Avoiding malloc for cases 3 and 4 would be a significant improvement
and #2 would be nice, but seems less important.
While there may be pathological cases involving floating point
types and unusually long exponents, I'm pretty confident that
even #1 would rarely require malloc'd storage in general.

BTW, are you sure that one needs so much memory to do proper rounding
in #1?  I wonder, because if that really is a fundamental requirement,
then no system with such a floating point format can do proper rounding
and also conform to the latest POSIX spec for snprintf.