snprintf w/o dependecy to malloc

Seems a good point. I will look into the implementation of snprintf to see whether it's possible.

Thanks for the suggestion.

Change status to answered

Hi, the malloc stuff is pulled in for asnprintf function. For both newlib and newlib-nano, snprintf shares this piece of code with asnprintf.
It's possible to not to pull in malloc for snprintf with more complicated code, but considering _malloc_r is only about 150 bytes, I am not very convinced that it should be done.

Any comments? Thanks.

Is my reply here of any use in this context?

https://answers.launchpad.net/gcc-arm-embedded/+question/233446

Hope this helps.

Thank you for the comments.

TM, yes, that question lists one aspect why dynamic memory allocation may not be wanted: On systems with very limited resources.

Another reason: There are software projects where dynamic memory allocation is simply not allowed, for example because of safety and/or deterministic reasons. One could argue that newlib is not the right candidate for these projects, but as long as there are no legal nor technical reasons not to use it and as long as the resulting code is tested very well, it may make sense.

And third group - simple projects where it is not needed by other parts of system, and providing malloc or sbrk only to use printf can be avoided.