Re: possible snprintf() regression in 3.3.2

[Sam Edge <sam.edge@gmx.com>]

On 18/11/2021 14:27, Corinna Vinschen via Cygwin wrote:

> On Nov 18 16:11, Noel Grandin via Cygwin wrote:
>>
>> On 2021/11/18 3:19 pm, Corinna Vinschen via Cygwin wrote:
>>> My patch raised NDEC from 43 to 1023 to allow aproximately the same
>>> number of digits as glibc.  Newlib strives to support embedded targets
>>> and bare metal.  Some of them are lucky if they have a stack size of 1K.
>>> The outbuf buffer is created on the stack, so I used ndigits to save
>>> stack space.
>>>
>>> While that patch fixes the reported problem, it will make users of
>>> smaller-than-Cygwin targets pretty unhappy.
>>>
>>> A workaround would be to malloc outbuf instead.  Given that printf
>> printf is often performance sensitive, and using malloc there would likely be significantly slower.
>>
>> Possibly use alloca() to allocate only the necessary amount on stack?
> That's kind of what the current code does.
>
> But that's apparently the problem.  The necessary amount is only known to
> the current algorithm while populating outbuf already.  So before my
> patch, outbuf had a constant size, but it was size restricted.
>
>> Seems unlikely that embedded systems would be printing values that needed such large space anyway.
> Perhaps that's a workaround:
>
> Use a constant buffer size, but use NDEC = 1023 only on Cygwin for the
> time being, something like NDEC = 64 otherwise...
>
>
> Corinna


Hi all.

I use newlib on embedded with threading libs that have predetermined
fixed thread stack sizes. While we tend to have more RAM than in former
times we also have multiple thread stacks. Use of alloca() or variable
length automatic arrays makes me wince especially in code I might not be
able to avoid calling which is often the case with XXXprintf() in
third-party libraries' debug output. I'd usually rather take the
performance hit from using heap instead of having to make all my stacks
bigger.

Just my two penn'orth.

Cheers.
--
Sam