Re: possible snprintf() regression in 3.3.2

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

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