Date: Mon, 7 Apr 2003 02:09:35 -0700 From: David Schultz <das@FreeBSD.ORG> To: Tim Robbins <tjr@FreeBSD.ORG> Cc: cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc/stdio vfwprintf.c Message-ID: <20030407090935.GA52480@HAL9000.homeunix.com> In-Reply-To: <20030407164849.A81391@dilbert.robbins.dropbear.id.au> References: <200304070636.h376anIZ039009@repoman.freebsd.org> <20030407164849.A81391@dilbert.robbins.dropbear.id.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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()!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030407090935.GA52480>