From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 20:30:19 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FB7B10656A8 for ; Wed, 8 Sep 2010 20:30:19 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 50FDE8FC14 for ; Wed, 8 Sep 2010 20:30:19 +0000 (UTC) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 253A95B38; Wed, 8 Sep 2010 13:30:18 -0700 (PDT) To: "Poul-Henning Kamp" In-reply-to: Your message of "Wed, 08 Sep 2010 19:18:33 -0000." <67864.1283973513@critter.freebsd.dk> References: <67864.1283973513@critter.freebsd.dk> Comments: In-reply-to "Poul-Henning Kamp" message dated "Wed, 08 Sep 2010 19:18:33 -0000." Date: Wed, 08 Sep 2010 13:30:17 -0700 From: Bakul Shah Message-Id: <20100908203018.253A95B38@mail.bitblocks.com> Cc: FreeBSD Arch Subject: Re: printf Re: Extending sbufs with a drain X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 20:30:19 -0000 On Wed, 08 Sep 2010 19:18:33 -0000 "Poul-Henning Kamp" wrote: > In message <20100908185848.96D5D5B81@mail.bitblocks.com>, Bakul Shah writes: > >On Wed, 08 Sep 2010 17:38:42 -0000 "Poul-Henning Kamp" > 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]