Re: About extensible prinf(3), a slightly long X-mas card

On Fri, Dec 16, 2005 at 10:01:03PM +0100, Poul-Henning Kamp wrote:
> Until somebody specifically ask for it (with a global variable or an
> environment variable) or registers an extension, we keep running on
> our good old fast spaghetti vprintf, but once extensibility is called
> for, we switch to my code.

Perhaps the semantics of this extended printf() are so far divorced from the
standard one that you might as well just call it something else? e.g.

    ext_printf()

or whatever. I can see two advantages to this approach:

(1) you don't take a big performance hit on all your other printf() calls
just because you used an extended format once in your code.

(2) clear marking of non-portable code: you are not tempted to use
non-standard features in a call to regular printf(), and end up with a
program which compiles happily on any other platform but dumps core when
run.

In fact, why not stick it in a completely separate library altogether,
rather than libc? That would greatly *assist* portability, since you could
simply build this library on other targets. In this case it would be OK to
call it printf(), as long as you don't mind the possible confusion and the
requirement to do your linking in the correct order.

> Obviously, such extensions are not condoned by style(9) but probably more
> damning, GCC's printf format checker knows nothing about them, so it will
> take a fit if you use them.
> 
> For these reasons, and for general reasons of sanity, printf format
> extensions should _not_ be added to FreeBSD programs at this time, if ever.

Sounds to me like another good reason for calling the function something
else, and/or putting it in a separate library.

Regards,

Brian.