printf Re: Extending sbufs with a drain

[Bakul Shah]

On Wed, 08 Sep 2010 19:18:33 -0000 "Poul-Henning Kamp" <phk at phk.freebsd.dk>  wrote:
> 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.

See Common Lisp's format function. Even its bells and whistles
have bells and whistles -- it may even be turing complete:-)
http://www.gigamonkeys.com/book/a-few-format-recipes.html
http://www.lispworks.com/documentation/HyperSpec/Body/22_c.htm

But then most things are easier in Lisp/Scheme & a wrong
format won't make your program crash.

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

Exactly. But some of us can't help attempting to do so!

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

How about somehow combining formatof with this?

Hmm.... how about a new specifier that means the next
argument is formatted with a function? For example, if
we use & as a fmt function specifier,

 	printf("Client address: %16&p\n", sa_fmt, &sa);
or more generally
 	printf("Client address: %16&" fmtof(&p) "\n", sa_fmt, &sa);

Now fmtof is used for typechecking and advancing over the
given argument but it is upto sa_fmt to convert sa to a
string.

Or how about visually embedding the function in the string?

 	printf("Client address: %16" @sa_fmt "\n", &sa);

The compiler would map this to the previous form.

[Throwing this out just in case it triggers some new ideas]