Rémi Denis-Courmont (12023-05-02):
> Indirecting the printf function seems pretty pointless. The last thing you 

Please re-read the code, there is no other way of obtaining a va_list
from an actual argument than making a call to a vararg function.

> want are different implementations of printf() with different limitations. And 
> it makes writing different backends needlessly complex, while you could just 
> use vasprintf().
> 
> Typically, with this kind of abstraction, only the raw bytes writing is 
> abstracted away. Examples include funopen() and fopencookie().
> 
> As for hypothetical use cases whence vasprintf() wouldb e "too slow", then 
> should not use printf()-style or function pointers to begin with. Besides if 
> you _really_ want to avoid the heap allocation, you can also use fopencookie() 
> on systems that provide it or equivalent.

Being portable and not doing dynamic allocation are two major points of
the design, so you will excuse me if I pass on that suggestion.

> That sounds like it belongs in whichever backend actually wants to heap-
> allocate the output buffer, not the frontend.

There is nothing about heap allocation in this code. And if code can be
in the framework common to all backends, then it is where it belongs,
not duplicated in each backend.

> This is an abstraction inversion (and also highly inefficient) + what I noted 
> above.

See above, it is necessary. (If you think it is not, try doing better.)

> This is an analogue of puts/fputs, not "print".

This is an analogue of puts, fputs and print, and I decided to call it
print.

> Same problems and overengineering as above.

I think you are missing something important about the purpose of this
code, but I cannot guess what exactly. Please be more detailed about why
you think it is overengineered and point how you would do it simpler.

Thanks for the comments.

-- 
  Nicolas George