raymond@ptolemy.arc.nasa.gov (Eric A. Raymond) (01/02/90)
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
chris@mimsy.umd.edu (Chris Torek) (01/02/90)
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