Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!uakari.primate.wisc.edu!ark1!nems!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Re^2: Variable Parameters
Message-ID: <21574@mimsy.umd.edu>
Date: 2 Jan 90 05:21:15 GMT
References: <1169@zip.eecs.umich.edu> <1989Dec31.013746.2349@utzoo.uucp> <3387@bacon.ptolemy.arc.nasa.gov>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 38

In article <3387@bacon.ptolemy.arc.nasa.gov> raymond@ptolemy.arc.nasa.gov
(Eric A. Raymond) writes:
[nargs() is]
>Difficult?  Expensive?  Not really, since at compile time each caller
>knows how many arguments it is passed, right?  (Note: this is true
>even if the function (i.e., called via a ptr) is unknown at compile-time.)

Difficult: no.  Expensive: possibly, although varargs functions are
relatively rare, so if this is done only for varargs functions, I would
say `probably not'.  But:

>... all we need to do is:
>  - count the number of (variable) args in each vararg function call
>  - pass the number of these args as an extra parameter
>  - make some function, say nargs(void), return the value of this
>    otherwise unavailable parameter.

>... it's not much to ask when one considers the benefits.

The benefits.  Aye, there's the rub.

C does not have values.  C has *typed* values.  You cannot ask or answer
anything about a value without first knowing its type.  For instance,
what value does the bit pattern 0x4120 represent?  Surprise, the answer
is `2.5', because I meant `VAX single precision floating point'.  (If
you had guessed 2.5, I would have said I meant an integer: 16772.)

There *are* functions that can get away with assuming a type---for
instance, execl() (or spawnl()).  They are not all that common: cf.
printf and scanf, which need types as well.

Even solutions of the form `pass a string denoting number of arguments
and type' can fall down, because there are complicated types that are
hard to describe: for instance, unions containing structures, and vice
versa.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris