3 ms·

Doesn't C's printf have the same problem?

codebje 7y ago
When using FreeRTOS tasks, any use of printf() requires a substantially larger stack allocation per task. But I don't recall now any massive blow-out in binary size.
- Gibbon1 7y ago
  Yeah canned printf is really stack heavy if I remember. A solution is to have one thread that handles printf. Biggest issue I've run into with printf at least in C is calling it tends to be expensive.
TickleSteve 7y ago
On embedded systems, it is quite common to have cut down libraries that only support a subset of types. e.g. floating point formatting is quite regularly left out.
uxp100 7y ago
Not really. It seems the problem for the author is that either they get string based output with a big printf, or no printf at all, and replacing printf is hard. In c replacing printf with a tiny limited implementation is easy and common.
saagarjha 7y ago
C doesn’t have ubiquitous calls to panic, so even if it did you generally don’t get it unless you do something which more obviously interacts with the formatting parts of the standard library.
__david__ 7y ago
Yes, in the sense that calling it anywhere will pull in a lot of stdlib stuff by default. But no, in that it's trivial in C to write your own minimal printf replacement. Because of the nature of linking in C, it will override all uses of it.
pcwalton 7y ago
Printf is basically a runtime interpreter, which has better code size, and worse performance, than the typed template magic that Rust uses. As other comments point out, though, printf in C can be a performance problem in embedded for this reason. Pick your poison…
rkangel 7y ago
In practice no, for several reasons: Embedded compilers quite often will include two implementations of printf/sprintf - 'minimal' and 'full' (like solution 2 in the post). Usually the 'minimal' implementation doesn't have floating point support and suchlike so is sufficient for normal debugging output. The sort of libraries that you depend on in embedded development don't implicitly print. There's none of the 'implicit panics will cause an extra 15k of space'. It's a normal symbol fed to the linker rather anything special and compiler managed so it can be overriden if necessary.

When using FreeRTOS tasks, any use of printf() requires a substantially larger stack allocation per task. But I don't recall now any massive blow-out in binary size.

Gibbon1 7y ago
Yeah canned printf is really stack heavy if I remember. A solution is to have one thread that handles printf. Biggest issue I've run into with printf at least in C is calling it tends to be expensive.

TickleSteve 7y ago

On embedded systems, it is quite common to have cut down libraries that only support a subset of types. e.g. floating point formatting is quite regularly left out.

uxp100 7y ago

Not really. It seems the problem for the author is that either they get string based output with a big printf, or no printf at all, and replacing printf is hard. In c replacing printf with a tiny limited implementation is easy and common.

saagarjha 7y ago

C doesn’t have ubiquitous calls to panic, so even if it did you generally don’t get it unless you do something which more obviously interacts with the formatting parts of the standard library.

__david__ 7y ago

Yes, in the sense that calling it anywhere will pull in a lot of stdlib stuff by default. But no, in that it's trivial in C to write your own minimal printf replacement. Because of the nature of linking in C, it will override all uses of it.

pcwalton 7y ago

Printf is basically a runtime interpreter, which has better code size, and worse performance, than the typed template magic that Rust uses. As other comments point out, though, printf in C can be a performance problem in embedded for this reason. Pick your poison…

rkangel 7y ago

In practice no, for several reasons: Embedded compilers quite often will include two implementations of printf/sprintf - 'minimal' and 'full' (like solution 2 in the post). Usually the 'minimal' implementation doesn't have floating point support and suchlike so is sufficient for normal debugging output. The sort of libraries that you depend on in embedded development don't implicitly print. There's none of the 'implicit panics will cause an extra 15k of space'. It's a normal symbol fed to the linker rather anything special and compiler managed so it can be overriden if necessary.