Re: glibc's snprintf is a pig; fix or replace ?

[Jim Meyering]

Pádraig Brady wrote:

> On 03/11/10 09:13, Jim Meyering wrote:
>> glibc's snprintf is next-to-useless in an application that must accept
>> arbitrary inputs and/or arbitrary format strings, and that cannot afford
>> to allocate 2GiB of heap.
>>
>> Did you know that glibc's snprintf can fail due to ENOMEM?  Your reaction
>> to that possibility should be disbelief.  But it's true.  Why does
>> snprintf allocate space from the heap for a format string like "%*d"?
>> I reported it as http://bugzilla.redhat.com/441945, but amazingly
>> enough, it was closed "NOTABUG".  The justification was that the POSIX
>> specification permits the current senseless behavior.  The letter of the
>> spec may permit it, but the spirit must not, so if indeed POSIX allows
>> the current behavior, the spec should be adjusted.
>
> Well heap allocation is blatantly silly/lazy/dangerous.

Actually it's not quite as bad as you might think.
It tries to allocate first from the stack, and if that fails,
it tries to allocate from the heap.  So both heap and stack
limits have to be taken into account.

But where/how it allocates is moot.  The point is that snprintf need not
allocate *at all* for all but a tiny fraction of format-string/value
combinations.