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

Poul-Henning Kamp phk at phk.freebsd.dk
Sat Dec 17 03:18:13 PST 2005

In message <20051217030513.A82342 at xorpc.icir.org>, Luigi Rizzo writes:

>> >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()
>> the reasons not to are
>> 	ext_printf()
>> 	ext_fprintf()
>> 	ext_sprintf()
>> 	ext_snprintf()
>> 	ext_asprintf()
>> 	ext_vprintf()
>> 	ext_vfprintf()
>> 	ext_vsfprintf()
>> 	ext_vasfprintf()
>> There is little or no point in replicating all of this stuff.
>phk, i don't understand your objection.
>aren't (or shouldn't) all of these written as wrappers
>for a generic ext_*printf() ?

My objection is that we would need an entirely new familiy
of wrappers such as the above.

>I love the idea of extensible printf, and it's way way useful
>when handling ip addresses, hexdump and whatnot; but
>portability is an issue, and nobody would use it if
>the source code doesn't port to other systems.

Everything under the sun has a portability cost these days because
the portable subset of the UNIX API is still too small to support
sensible programming.

My favourite example is this:  After 30 years, wouldn't you
have expected that UNIX would sport a:

	open_tcp_connection(const char *host, const char *proto)

call ?

Try to compare the primitives modern languages offer to what
you can portably use on UNIX and see the disparity :-(

The sorry situation is that after Dennis and Ken let go, nobody
has been able to work on th UNIX API in a coherent fashion, and
instead various extensions have been slapped on haphazardly where
people could fit them in.

For an extensible printf, I see little reason to add yet another
API, the GLIBC people got here first, the API is not optimal, but
it does work.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the freebsd-current mailing list