AVR has no vprintf_P?

Question

Well this was unexpected. AVR libc has many the variants of printf, including vprintf, but is missing vprintf_P. Is this really just not present or implemented elsewhere?

Answer 1

It has vfprintf_P and stdout is a FILE. Why would you want to waste time and space with implementing vprintf_P as well?

If you really want it, you can make your own:

#define vprintf_P(...) vfprintf_P(stdout, __VA_ARGS__)

Incidentally, the source code to vprintf looks like this:

int
vprintf(const char *fmt, va_list ap)
{
 return vfprintf(stdout, fmt, ap);
}

That does exactly the same job as a preprocessor macro - just forwards your request on to the FILE-based function.

It is actually more efficient to use a preprocessor macro than needlessly nesting functions like that - less stack usage, less calls, etc (unless the compiler happens to choose to inline that function, which since it is in a library it likely won't).

The non-FILE based functions can be considered simple wrapper functions to the FILE-based ones. They are mostly provided for convenience, but are actually completely redundant and can all be replaced with direct calls to the FILE-based variant. They mostly still exist purely for historical compatibility. And since _P is specific to AVR libc there is nothing historical for it to be compatible with.

• Ana: That wouldn't be a good explanation for why it does have printf, sprintf, snprintf, vsprintf, vsnprintf, fprintf, vfprintf and all of their _P variants, would it?
• Majenko: It would be just idiotic to miss out printf. All the others either take a file or string as their target, which means they are the base ones. All other functions can be made from them. You don't like it? Then submit a patch to the repository and stop complaining.
• Ana: Wow. Fair question met with an obnoxious attitude. Okay, I'm going to go waste everyone's time and space with the patch!
• Majenko: I was going to say the same thing - fair answer met with an obnoxious attitude. You ask a question, get the answer, but don't like that answer because it doesn't agree with the answer you have already formulated inside your head, so start with the 'tude.
• Ana: I asked yes/no question. I would've accepted the answer "no, it's not implemented". I didn't ask for your opinion on whether the function is a waste of time and space, did I? It's also a laughable answer in itself since you yourself illustrated that it's a trivial one-liner. That's okay. This is all public. Let others judge.