From owner-cvs-src@FreeBSD.ORG Mon Apr 7 02:09:42 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C66AF37B401; Mon, 7 Apr 2003 02:09:42 -0700 (PDT) Received: from HAL9000.homeunix.com (12-233-57-131.client.attbi.com [12.233.57.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCDDB43FA3; Mon, 7 Apr 2003 02:09:41 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) h3799ZKj052726; Mon, 7 Apr 2003 02:09:35 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6p2/8.12.5/Submit) id h3799ZUw052725; Mon, 7 Apr 2003 02:09:35 -0700 (PDT) (envelope-from das@FreeBSD.ORG) Date: Mon, 7 Apr 2003 02:09:35 -0700 From: David Schultz To: Tim Robbins Message-ID: <20030407090935.GA52480@HAL9000.homeunix.com> Mail-Followup-To: Tim Robbins , src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org References: <200304070636.h376anIZ039009@repoman.freebsd.org> <20030407164849.A81391@dilbert.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030407164849.A81391@dilbert.robbins.dropbear.id.au> cc: cvs-src@FreeBSD.ORG cc: src-committers@FreeBSD.ORG cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdio vfwprintf.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2003 09:09:43 -0000 On Mon, Apr 07, 2003, Tim Robbins wrote: > On Sun, Apr 06, 2003 at 11:36:49PM -0700, Tim J. Robbins wrote: > > > tjr 2003/04/06 23:36:49 PDT > > > > FreeBSD src repository > > > > Modified files: > > lib/libc/stdio vfwprintf.c > > Log: > > Catch up with recent vfprintf.c changes. > > This (and vfprintf.c) have evolved into something utterly disgusting and > could probably do with a rewrite using a suitable structure, instead of > "one big function with one big switch statement". Agreed. The aspect of the design that prevents the various parts of printf() from being abstracted away in a reasonable way is the fact that the output routines are macros that modify local state and even 'goto error'. With the current design, *everything* that wants to output has to be in __vfprintf(). Moreover, the macros are expensive space-wise when they get expanded many times. On the other hand, it is also desirable not to malloc lots of little buffers and copy everything thrice for every printf() call. The start of a solution may be to treat the 'struct uio' in __vfprintf() as the context for the buffer, which can be passed to subroutines that have the side-effect of outputting characters to it. Also, notice that the output routines use an array of I/O vectors internally. This is potentially *very* useful, since it could be used to avoid having a two-stage algorithm where we determine the size of the thing we are going to output in the first stage, then actually output it later on. Specifically, if you have to output left padding, you can leave an iov as a placeholder, then fill in the details later when you know the size of everything else. I suppose with all the fiddling I did with the FP code, I might as well have refactored all of __vfprintf(), but it's too late now. If you have any ideas about how to better structure __vfprintf(), I would love to hear them. However, I won't have any free weekends to devote to aiding in a major assault on __vfprintf() anytime soon. Thanks for merging the changes into __vfwprintf()!