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

[Pádraig Brady]

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.
Has that always been the case? It's been the case for long
enough that a replacement is warranted I suppose.
Will we eventually replace all of glibc as it accretes bugs over time :(

It's a pity that bug is closed.
What's the process for appealing this?
I notice no voting feature for example.

cheers,
Pádraig.