cvs commit: src/lib/libc/stdio vfwprintf.c

[David Schultz]

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()!