printf Re: Extending sbufs with a drain

[Bakul Shah]

On Wed, 08 Sep 2010 17:38:42 -0000 "Poul-Henning Kamp" <phk at phk.freebsd.dk>  wrote:
> 
> >In the end I would like a One True Printf to bind them all[...]
> 
> You and me brother, amen!
> 
> I don't think an OTP is possible without compiler and language
> support, and since the ISO-C people seems to have evaded this desire
> to the full extent of their ability, it is probably never going
> to happen in the C language.
>
> For one thing a OTP would allow you to define type specific formatters,
> sort of the way the chapter 1. example in any C++ book teaches with
> the << operator.  But this would require passing not only the varargs
> but also their types to the formatting function.

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. Should it be "%{%d, %d%}" or
"%{x=%d, y=%d%}" or something else? Either would be enough
for a compiler to check argument validity but there is no
flexibility.  Beyond that, an additional complication is in
dealing with all the "optional" flags, width, precision,
alternate formats etc.  May be that can be dealt with by a
set of auxiliary functions or a heavily overloading formatof.
But I just don't think there exists a solution that is type
safe, flexible and simple enough (the cure should not be
worse than the disease).

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]

> It would be trivial for the compiler to insert a type specifying
> enum/bitmap before every argument, so that printf and any other
> varargs using functions knew what it was dealing with.  I kind of
> like this idea, as it basically makes varargs typesafe, but obviously
> ISO-C think it is not kosher.

I suspect it is more that no one has come up with a model
that is appealing enough.  In any case they might be more
amenable if a prototype exists.  Face it, C is just a block
structured assembly language!  Personally I think the idea of
extending C has jumped the shark long ago.