Reduce stack usage of _vfiprintf_r()

Federico Terraneo
Thu Oct 11 17:30:00 GMT 2012

Hash: SHA1

On 10/10/2012 07:08 PM, Freddie Chopin wrote:
> W dniu 2012-10-10 18:27, Federico Terraneo pisze:
>> I seem to be missing something: the cod you posted contains an 
>> unconditional
>> buf = _malloc_r(rptr, BUFSIZ);
>> which as I have understood is a replacement for
>> unsigned char buf[BUFSIZ];
>> Now, if the function is never called, the buffer is never
>> allocated in both cases. On the other hand, if the function gets
>> called, in both cases it will reserve 1024 bytes, either on the
>> heap or the stack. I don't see how your patch would entirely
>> prevent the reservation of 1024 bytes in the case of unbuffered
>> streams.
> See my previous posts - __sbprintf() is inlined into
> _vfiprintf_r() (because it's static and used only in
> __vfiprintf_r()), thus the buffer on stack is ALWAYS allocated,
> while the dynamic allocation is performed only is the code is
> executed.

Now it makes sense. I am going to try adding an


to that function (a GCC-specific extension to forcefully disable
inlining) and see if it makes a difference.

> Glad to hear that I'm not the only one that thinks newlib is "too
big" (;

I went through that in the beginning, when moving from AVR
microcontrollers. I was a bit puzzled discovering that a simple
printf() can add 40KB to your code, but over time I appreciated the
standard compliance of newlib, and won't move again to a C library
which only provides a subset of the standard. After all,
microcontrollers with ~128KB of FLASH are cheap, and provide room for
a surprising amount of C (and C++) stdlib support. RAM usage is a bit
more of a pain, but it's still acceptable.

Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the Newlib mailing list