> to get printf() to do what you're suggesting. I have
> serious doubts it can even be made to do what you want in C

Interesting, Thiago. Why not?

> What makes you think that it's a small change to printf?

Am basing my thinking on the fact that modern C compilers warn on type
mismatch in printf, even say what the type is and what the right flag
would be.

> If they are using that in C++, at the next refactoring opportunity,
> they should update to std::format and std::print, dispensing of the
> printf() code in the first place.

No, often best to not replace working legacy C code with fresh C++ code
to do the same thing. Too expensive.

I've been refactoring legacy code for decades, yet can't recall a
"refactoring opportunity". I'm just fixing new warnings in old code
generated by improved compilers. Yes, I can cast to (int) to silence
such warnings. But if being cavalier, it would be quicker to silence the
warning systemwide using a compiler flag. To respect the warning,
correct it without a cast, is the goal.

> what global lock?

Am referring to the global new lock. Typically hidden in std::string
when it calls new to create a string buffer.

There is of course no requirement that std::string call new or that new
has a global lock on the heap. However, it is what we may expect. And
not consistently, by the way, as a common implementation optimization
keeps strings of 23 bytes or less in an array, does not call new until a
longer string is needed.

 From experience, I know that iostream operations can be much slower
than printf. In the past I have written my own iostream and string
libraries that replace the std versions as a drop-in replacement to get
the performance needed.

> If so, please provide a link to your repository with the proof of
concept.

No, I haven't created my own fork of clang or gcc with a custom printf.

Repo? If anyone is curious, here's the legacy code I'm updating that has
me thinking about how printf might be improved...
https://gitlab.com/robinrowe/gtk1

Robin