Comment by tails4e
1 day ago
I thought this was going to talk about how printf is implemented. I worked with a tiny embedded processor that had 8k imem, and printf is about 100k alone. Crazy. Switched to a more basic implementation that was around 2k, and ran much,much faster. It seems printf is pretty bloated, though I guess typical people don't care.
In most C standard libraries intended for embedded applications, including newlib, there is some configuration option to provide a printf that does not support any of the floating-point format specifiers.
That is normally enough to reduce the footprint of printf by more than an order of magnitude, making it compatible with small microcontrollers.
I implemented a secure printf_s and its API is the problem. You cannot dead-code eliminate all the unused methods. And it's type unsafe. There are much better API's to implement a safe printer with all the formatting options still. format is not one of them
The only hack I could think of is having the compiler front end generate calls to different functions based on the content of the format string, similar to how some compilers replace memset with a 32-bit memset based on the type of the destination pointer
And it all falls apart as soon as a format string cannot be known at compile time.
> The only hack I could think of is having the compiler front end generate calls to different functions based on the content of the format string
Compilers do that, at least for the simple case of constant strings; gcc can compile a printf call as puts. See https://stackoverflow.com/questions/60080021/compiler-change...
2 replies →