From owner-freebsd-arch@FreeBSD.ORG Wed Sep 8 19:18:35 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 8B71410656D5 for ; Wed, 8 Sep 2010 19:18:35 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD3E8FC12 for ; Wed, 8 Sep 2010 19:18:34 +0000 (UTC) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 11AF03F61A; Wed, 8 Sep 2010 19:18:34 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.4/8.14.4) with ESMTP id o88JIXDh067865; Wed, 8 Sep 2010 19:18:33 GMT (envelope-from phk@critter.freebsd.dk) To: Bakul Shah From: "Poul-Henning Kamp" In-Reply-To: Your message of "Wed, 08 Sep 2010 11:58:48 MST." <20100908185848.96D5D5B81@mail.bitblocks.com> Date: Wed, 08 Sep 2010 19:18:33 +0000 Message-ID: <67864.1283973513@critter.freebsd.dk> Sender: phk@critter.freebsd.dk 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 19:18:35 -0000 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. 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@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.