4 ms·
While "newlib" is an interesting idea - the approach taken here is, in many cases, the wrong one. You see, actually, the printf() family of functions don't act
by einpoklum 2y ago
While "newlib" is an interesting idea - the approach taken here is, in many cases, the wrong one.
You see, actually, the printf() family of functions don't actually require _any_ metal, bare or otherwise, beyond the ability to print individual characters.
For this reason, a popular approach for the case of not having a full-fledged standard library is to have a fully cross-platform implementation of the family which "exposes" a symbol dependency on a character printing function, e.g.:
void putchar_(char c);
and variants of the printf functions which take the character-printing function as a runtime parameter:
int fctprintf(void (*out)(char c, void* extra_arg), void* extra_arg, const char* format, ...);
int vfctprintf(void (*out)(char c, void* extra_arg), void* extra_arg, const char* format, va_list arg);
this is the approach taken in the standalone printf implementation I maintain, originally by Marco Paland:
https://github.com/eyalroz/printf https://github.com/eyalroz/printf
- eqvinox 2y agoAs replied on your other comment, when you introduce a custom printf for an embedded platform it makes more sense to just edit in support for your local I/O backend rather than having the complexity of a putch() callback function pointer. cf. https://news.ycombinator.com/item?id=43811191 https://news.ycombinator.com/item?id=43811191 for other notes.