varargs functions - why tell the caller?

[Kevin Martin]

Having the caller generate special code to call functions wanting arbitrary
arguments has a couple of problems:
1) You can't take a pointer to a varargs function, give it to another
   function, and allow the other function to call the varargs function.
   I don't see a clean way to say "this object is a pointer to a varargs
   function" when 'this object' could be any C name or aggregate element.
   Even if there were a syntactic method of solving this problem, you would
   need to have two versions of any function which wants a passed function:
   one which does a normal call, one which does the varargs call.
2) You should be able to call any function by correctly declaring its return
   value, and correctly *casting* the arguments. You shouldn't have to give
   a declaration for the arguments (otherwise you end up with Pascal)

Provided that the callee always knows the type of the next argument (actually,
the 'passed' type e.g. 'int' when a char is expected), the caller doesn't
need to know about the varargs entry. It may be necessary to put a special
declaration where the function is defined, however.

The Berkeley <varargs.h> include file gives an almost sufficient set of
macros for doing the varargs *portably*. It lacks the ability to align
the pointer to the next argument properly (until C has an alignof operator,
this will be effectively impossible). Its other failing is that it does not
define a special marker to put *before* the function.

The structure of the argument list, the name of the formal parameter(s),
and the declaration of the formal parameter(s) are all hidden by these macros,
thus they can be changed in whatever strange manner is required by the
environment.