Reduce stack usage of _vfiprintf_r()

Federico Terraneo
Wed Oct 10 18:05:00 GMT 2012

Hash: SHA1

On 10/10/2012 06:15 PM, Freddie Chopin wrote:
> W dniu 2012-10-10 17:59, Federico Terraneo pisze:
>> first of all, am not a newlib devloper, just a regular user. I
>> noticed the exact same problem in RAM constrained ARM
>> microcontrollers when using newlib together with an RTOS that I
>> developed. The solution I found is different though, and is to
>> apply a simple patch to newlib that redefines BUFSIZ to 512
>> instead of 1024. That small change later became part of a larger
>> patch that can be found here: 
The relevant lines are 32--39.
> Glad to hear that I'm not the only one that thinks newlib is "too
> big" (;
> Your solution is "not good enough" - the stack is still wasted,
> 512 bytes is still a lot - considering that _vfiprintf_r() with my
> patch uses about 300 bytes of stack, the 512 byte buffer almost
> triples that usage, so for me that's still too much (; I think
> dynamic allocation in this place is perfectly reasonable - whatever
> overhead does malloc have it's better than wasting such amount of
> stack in every situation (as proven in the first mail). In case of
> my code I don't expect it to be ever called, because I don't use
> unbuffered streams.

I seem to be missing something: the cod you posted contains an

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.

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


More information about the Newlib mailing list