gripe: variable arg lists

[Kevin Martin]

>> But there is a standard method of dealing with variable argument lists.
>> 	#include <varargs.h>
>> The contents of the file differ from machine to machine, but the `entry
>> points' are standard.
>
>Unfortunately, the ability to implement <varargs.h> is, to some extent,
>machine-dependent.  There are some machines where variable argument lists
>are very hard to do, and must be kludged in very machine-dependent ways.
As long as they can be kludged.
That's why the definitions are hidden in an include file. That way, to
the user, they don't appear machine-dependant.

>> As to why _doprnt() was used: that's pretty easy.  There is no standard
>> analog to printf which accepts a variable argument list *as an argument*.
>
>There is, however, a portable mechanism to do this job:  sprintf followed
>by passing the resulting string to whoever wants it.
>				Henry Spencer @ U of Toronto Zoology


How about another addition to <varargs.h>, which, given a function,
its return type, and one of the (partially-used) va_list's, passes
the remaining arguments referred to by the va_list to the function?
  retval = va_apply( printf, int, nextarg );
Obviously, va_apply is a macro, but it usually needs a library routine
written in (shudder) assembler to copy and build another argument list.

Unfortunately, you still can't call fprintf unless the arglist YOU
are given also contained the file pointer. va_apply has no way of passing
args which *aren't* in the given arglist. Maybe a more general way of
building an arglist to give to va_apply is required...

(Yes, we have implemented va_apply, and I have used it)
               Kevin Martin, UofW Software Development Group