About extensible prinf(3), a slightly long X-mas card
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
>> 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
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)
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