Just another good reason not to implement printf() yourself

Dear re-examining IOTlers,

I know a lot of us have been unhappy with (some aspects of) Newlib for a long time, including the somewhat bloated implementation of printf(). However, there are IMO various good reasons not to implement printf() ourselves. https://guidovranken.wordpress.com/2016/02/27/openssl-cve-2016-0799-heap-corruption-via-bio_printf/ gives just another good example, what could go wrong.

Cheers, Oleg

Hello Oleg,

what about to have at least “official” wrapper around printf?

Im using tinyprintf already with riot and to have PRINTF macro defined would make things much easier. There are DEBUGs and LOGs together with printf-s sprinkled in the code. While DEBUG and LOG can be defined to custom functions, printf no. Thinking at printf.h with PRINTF macro + formatter macros defined - bad idea?

wbr malo

Hey malo!

Hello Oleg,

that would be even better indeed. something like #define LOG_PRINTF(…) LOG(LOG_PRINTF, VA_ARGS) and to forbid to use printf?

wbr malo

Hey Malo!

that would be even better indeed. something like #define LOG_PRINTF(...) LOG(LOG_PRINTF, __VA_ARGS__) and to forbid to use printf?

Hm, after thinking about this again, it's a bit more difficult, I guess. There are three types of actions where I see a need for printing strings: 1.) logging (something similar to syslog or journal on Linux) 2.) debugging 3.) some kind of CLI (e.g. our shell)

1.) should be covered by LOG_* from log.h. 2.) is covered by DEBUG() 3.) still needs a concept

But in general, I agree that getting rid of printf() all over the code is desirable.

Cheers, Oleg

Hello Oleg,

To make it really usable for alternative printf some cleanup in the formatting strings would be desirable as well.

since at the mo there is the mix of direct formatting string with macros like PRIi16…

wbr malo

Hi Oleg,

[...]

I know a lot of us have been unhappy with (some aspects of) Newlib for a long time, including the somewhat bloated implementation of printf(). However,

just curious what the concerns about bloat are. Is it related to not-optimized implementation, or providing options that aren't needed?

Thanks, Paul

Hi Paul!

Hi Malo!

Hello Oleg,

PRIu16 was not good example, PRIi8 is better, since it translates for example to “hhi” in my case, which is not so widely supported by minimal printf implementations.

if you want to use formatting macros I would go with one additional layer of macros like by default #define _PRIi8 PRIi8, that can be easily changed at one place.

as for the most un needed option of the year 2016:) - my target is riot running 6lowpan host with 6lowpan ndp support plus coap server on 8kB of ram. so do not have that much memory to waste for printf. Am I the only one?

wbr malo

Hey,