printf

A popular standalone printf-family library in the embedded world is, well, printf : https://github.com/eyalroz/printf which is independent of a C standard library (it doesn't actually do any I/O itself). Originally by Marco Paland, now maintained, or 'curated' by myself (so, this is a bit of a self-plug, even though I can barely claim authorship). It offers this generalization : 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); The library is not performance-oriented, but rather small-code-size-oriented. The family of functions therefore all have a single backing implementation. You might think that implementation must use the function generalization quoted above, but actually it uses a

Maybe the rabbit hole is much deeper than it seems. Is it really possible to reconcile "no bloat" with "fully standard compliant"? Maybe have a look at https://github.com/eyalroz/printf, if only for the test suite, which looks pretty comprehensive and still fails. Maybe "key features" does not mean the same in all projects, making every project appear "unnecessarily bloated while missing key features" in every other context?

> Is it? Could you elaborate/provide links to examples of this? https://github.com/FRRouting/frr/tree/master/lib/printf Disclaimer: my work. Customised to support %pHX, %pI4, %pFX, etc. - docs at https://docs.frrouting.org/projects/dev-guide/en/latest/logg... for what these do. > What customization would it support? I don't understand your question. It's reasonably readable and understandable source code. You edit the source code. That's the customisation? > Say, compared to these options: https://github.com/eyalroz/printf?tab=readme-ov-file#cmake-o... First, it is customary etiquette to indicate when linking your own code/work. Second, that is not a POSIX compatible printf, it lacks support for '%n$' (which is used primarily for localisation). Arguably can make sense to omit for tiny embedded platforms - but then why is there FP support?

Is it? Could you elaborate/provide links to examples of this? What customization would it support? Say, compared to these options: https://github.com/eyalroz/printf?tab=readme-ov-file#cmake-o...

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 take

> with file specific flags But you don't want to disable warnings throughout the file, just locally. > Then you don't have non-portable cruft littering the code, You can make it perfectly portable, with a little macro work. See, ,for example: https://github.com/eyalroz/printf/blob/013db1e345cbb166a7eb7... (this is from the standalone-no-libc-printf-family-implementation I maintain; the library is C, the test suite is C++ but it doesn't matter for the purposes of my point here.) and that you only need to do once in your project (you can make it your own header). Even when it comes to use - you can place your warning-disabling within another macro, so that you end up only using a simple single macro for your actual code.