Bruno Haible <[EMAIL PROTECTED]> 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.
