Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.lang.c
Subject: Re: gripe: variable arg lists
Message-ID: <1164@umcp-cs.UUCP>
Date: Fri, 16-Nov-84 21:01:41 EST
Article-I.D.: umcp-cs.1164
Posted: Fri Nov 16 21:01:41 1984
Date-Received: Sun, 18-Nov-84 03:34:25 EST
References: <348@gitpyr.UUCP>
Distribution: net
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 25

There are times when it is important to be able to get at the innards
of printf (i.e., _doprnt or _printf or _foobar or whatever the XYZ
software co. calls it), because the existing functions just don't Do
What You Want.  There is a wonderfully nearly portable way to do this,
and that is the v*printf routines in System V.  Sigh.

Even those may not Do What You Want.  Probably the most general way
to do things would be to have a routine called func_printf, which
takes a function $f$, an argument $caddr_t arg$, a format $fmt$, and
a variable argument list a la printf and friends.  Then the routine
that actually implements printf() et al. could call $f$, giving the
character to be printed and the extra $arg$.  If $caddr_t$ is the
generic pointer type, you can then squeeze all needed info into a
structure and pass its address.

Of course, such an implementation would be terribly inefficient for
ordinary stdio file I/O...

In the meantime, I've got #ifdef pyr's in my Emacs source.  Sigh.
-- 
(This line accidently left nonblank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland