This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reduce stack usage of _vfiprintf_r()


-----BEGIN PGP SIGNED MESSAGE-----
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: 
>> http://gitorious.org/miosix-kernel/miosix-kernel/blobs/master/miosix/compiler/gcc-patches/newlib.patch
>>
>>
>> 
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
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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQdaHXAAoJECkLFtN5Xr9fZzgIAI9WJ0/mP8cA/pU+oLHPd90u
jeanU3bcqx0oidRh/zEyE8DFG4v1ZdWxNEAGxS8wZ7wyOBdkMBrSh5gqGLc6Dk7g
QqMQ4tFgxb4aA06ZWVhgtNX/rNZbbiOH3/x1N4sIwi+n2Vwfipnk9HbZX1FGA97m
EbHJL0k3nEupMmNqFoe0f0ifEQpUwrIuTdYjRyzaYo2Z5mhzin4LQ8iBfTqSwN8d
LYHNyVe9pqOMcSofRSAxdTrjaMn7vo7Xm1d9OEyL0ueXP3JC48k6tD4OvoB+bMkC
m/qHBxELQ2yZV/5akW1ObwgzxiggrT+CMMOab3NzwSpI3KoQFH32aEC+BxUi9Jc=
=ZgIV
-----END PGP SIGNATURE-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]