Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!eos!ptolemy!raymond
From: raymond@ptolemy.arc.nasa.gov (Eric A. Raymond)
Newsgroups: comp.lang.c
Subject: STDARG.H (va_arg stuff) ineffective
Message-ID: <1077@ptolemy.arc.nasa.gov>
Date: 7 Apr 89 21:25:46 GMT
Reply-To: raymond@ptolemy.arc.nasa.gov (Eric A. Raymond)
Organization: NASA Ames Research Center, Moffett Field, CA
Lines: 39


The variable argument facility as provided by STDARG.H (in the ANSI
standard?)  appears to have a severe limitation.  Any additional
arguments you supply in the caller are retrieved as a list of args.
Unfortunately there is no way to know when you have reached the end of
this list.

Thus if you have a function F(a,b,c, ...) and two calls to it F(1,2,3)
and F(1,2,3,4), there is really no way to know that an optional
argument was passed (or was not passed).  What I really want is
something to approximate the expressiveness/flexiblity of &optional or
&rest in Lisp.

In order to make this work, you must provide info about the variable
args in the fixed arguments (a,b,c) or always include some end of list
value as the last argument.  But this means that you always have to
include this value even when you don't have any variable arguments.
(Also, there must be some value which is not valid over the union of
all possible variable arguments.)

I suppose the reason for this is efficiency.  The caller need only
push the extra args somewhere and not construct a real list.

Possible solutions require compiler support: 
 - Construct a real list such that the end of the list is nonambiguous
 - Pass a count of the args such that a va_arg will decrement it and a
   predicate (i.e. va_argp()) to test whether args are left.

This appears to have the same philosophical roots as passing arguments
by reference in C.  That is, in order to acheive X, both the caller
and callee must have have similar explicit notations.  I call this the "write
it in two places" syndrome.  This is also manifest in the header
file/source file redundancies (where you must maintain two files with
essentially the same (subset) information.  Flame and I'll explain.
(but this is a seperate issue).

-- 
Eric A. Raymond  (raymond@ptolemy.arc.nasa.gov)
"A hungry mob is an angry mob"