You can also use __attribute__((format(printf, ...))) for functions of yours that ultimately pass their varargs to a member of the printf family.

It is exceedingly rare for malloc() to give you a recovery chance on failure. Folks are so used to the Linux model of overcommit+OOM killer that almost nobody's code can gracefully deal with memory exhaustion.

> printf may malloc so don't use it in an out of memory situation. Though I think this problem is vanishingly unlikely these days.

Alternatively: don’t call printf from your interposed malloc, bad things will happen ;)

> 1. printf may malloc so don't use it in an out of memory situation. Though I think this problem is vanishingly unlikely these days.

I'd like to point out that FreeBSD's printf only does this if:

1. you use a lot of arguments (i.e. a compile-time decision, and quite rare)

2. use wchar_t support (also a compile-time decision and quite rare)

3. the output is to something that buffers/mallocs (i.e. stdio)

4. locale support does it for some reason (I simply haven't checked this)

Which makes it great to use in e.g. crash handlers. It's actually Async-Signal-Safe if you cut out the stdio bits. And it's available under BSD license... and actually a nice read (more on that in a separate post.)

>1. printf may malloc so don't use it in an out of memory situation. Though I think this problem is vanishingly unlikely these days.

I feel like you've just saved my future self from a terrible bug in the future. Thanks

Also, don't use printf in a signal handler for the same reason. Any attempt to malloc or free within a signal handler context runs the risk of a deadlock.

4. On GNU/Linux you can add your own %-conversions (e. g. %Y) with register_printf_function.

register_printf_function is deprecated; you should use register_printf_specifier instead.

I strongly advise against using either since both are not only non-portable, but also break any compiler support for getting you warnings when you're using it wrong.

The Linux kernel style suffix extensions (cf. https://www.kernel.org/doc/Documentation/printk-formats.txt) are much better on the latter front.

> 1. printf may malloc so don't use it in an out of memory situation. Though I think this problem is vanishingly unlikely these days.

You can avoid this by doing something like:

  setvbuf(stdout, NULL, _IONBF, 0);

You sure about that? This seems to suggest otherwise: https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-commo...

It will allocate a buffer on the stack:

https://sourceware.org/git/?p=glibc.git;a=blob;f=stdio-commo...