printf Re: Extending sbufs with a drain

[Poul-Henning Kamp]

In message <20100908185848.96D5D5B81 at mail.bitblocks.com>, Bakul Shah writes:
>On Wed, 08 Sep 2010 17:38:42 -0000 "Poul-Henning Kamp" <phk at phk.freebsd.dk>  wrote:

>If it was just printf/scanf family, one can perhaps hack
>gcc/clang to generate a default fmt string for each type,
>available with a `formatof' compile time function. Then one
>can do, for example,
>
>    struct {int x, y;} z;	
>    printf("z=" formatof(z) "\n", z);
>    printf("z->" formatof(&z) "\n", &z);
>
>But even for such a simple case most of us would disagree on
>just what formatof(z) should be. 

Indeed, not to mention that we still want to retain the padding/
width specifcation so things can be aligned nicely over multiple
lines.

There are conflicting issues here, but they all boil down
to the look of the source-code.

It is instructive to notice that the C++ "<<" stuff never really
hit the mark except as a convenient debugging facility:  Most people
still fall back to *printf() for the actual formatting.

If you survey other programming languages, the best they do is
provide a default string representation, but seldom with any
bells and whistles.

And at least my attempts at a sensible advanced printf syntax
has been anything but, making the lines sufficiently unreadable
that I couldn't be bothered.

I think the strength of the printf model is that the format spec
is very compact, as soon as you embellish it, the model falls apart,
and you suddenly need really strong compile-time checks to not make
silly mistakes.  (in the absense of typesafe varargs).

If we can get over the disappointment of not being able to write
the entire formatting statement in a single transparant source line,
sbufs are an eminently workable solution, in that you can define 
your own formatting functions, like:
	sbuf_sockaddr(struct sbuf *, struct sockaddr *)
and call that as much as you want, without getting bogged down in
error checking.

But:
	sbuf_cat(sb, "Client address: ");
	sbuf_sockaddr(sb, &sa);
	sbuf_cat(sb, "\n");

Does not compete with:

	printf("Client address: %{DWIM}\n", &sa);

In any other way than by being feasible and available.

>This is why I like the plan9 idea of allowing users to
>associate their own function with a given format char.
>[you don't get type safety but you get flexibility]

We have that, see /usr/include/printf.h for userland.

Problem is that the benefit from using it is quickly lost to not
having any printf format-checking from the compiler anywhere.

>Personally I think the idea of extending C has jumped the shark long ago.

The problem is that we failed to maintain C as a cutting edge
language and instead fell back to working around its shortcomings
with all sorts of tools, from lint to Coverity.

Now the same tools prevents us from updating C to have sensible
contemporary features.

Poul-Henning

-- 
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.