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
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
