kpmartin@watmath.UUCP (Kevin Martin) (07/12/84)
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.