Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ames!eos!ptolemy!raymond
From: raymond@ptolemy.arc.nasa.gov (Eric A. Raymond)
Newsgroups: comp.lang.c
Subject: Re^2: Variable Parameters
Message-ID: <3387@bacon.ptolemy.arc.nasa.gov>
Date: 2 Jan 90 00:43:21 GMT
References: <1169@zip.eecs.umich.edu> <1989Dec31.013746.2349@utzoo.uucp> <363@sixhub.UUCP> <1990Jan1.004914.25006@utzoo.uucp>
Organization: NASA Ames Research Center
Lines: 44

henry@utzoo.uucp (Henry Spencer) writes:

>In article <363@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes:
>The fundamental problem with finding out how many arguments you have --
>ignoring the problem of varying sizes, which got much worse when C
>acquired struct passing -- is that in general you need cooperation
>from the caller.  On some machines, the information can be deduced
>from details of the stack frame or the calling sequence, but on many
>modern systems, it has to be explicitly provided at significant cost.
>Given the call-intensive nature of a lot of C programs, it is a seriously
>bad idea to incur such cost on every function call, given that most
>functions never need the information.

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.)

Assuming every vararg function call / definition exists within the
scope of a prototype, 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.

Note that the only (runtime) cost is that of passing another argument
when the prototype of the function is declared to use varags.  This is
the only major drawback to this approach, but it's not much to ask
when one considers the benefits.  (Of course, dusty decks out there
may need a bit of help ....).  Even if the function is variable (i.e.,
call via ptr), the use of function prototypes provides us with the
info we need.  (That is, the ptr is strongly typed.)  And of course we
all use pointers.

This might be hard to implement as a macro package. (but why should
language features be limited to what can be expressed in it's macro
language).  Implementing it in a compiler should be fairly straight
forward.

So there's one solution.  A language should not be limitted by the
"that's the way it's been done" factor.

-- 
Eric A. Raymond  (raymond@ptolemy.arc.nasa.gov)
G7 C7 G7 G#7 G7 G+13 C7 GM7 Am7 Bm7 Bd7 Am7 C7 Do13 G7 C7 G7 D+13: Elmore James