A stupid way to do variable # of arguments?

[warren at tikal.UUCP]

There is obviously one reasonable way to handle varargs, but it requires
a language extension similar to the one proposed by Tom Haapanen, that is,
make varargs a part of a function type:

	The function itself:

	varargs char * printf (argc, argv)... /* Just like main */
		/* Note it would NOT be safe to assume that a null pointer
		 * exists at the "end" of the list unless this were in the language
		 * definition...
		 */

	When using the function:

	extern varargs char * printf ();	/* variable number AND type   */

	The CODE GENERATED by the compiler for the call to printf (my example)
	will be drastically different because of the varargs definition.  For
	example, it will push arguments (R to L) then push the array of pointers
	and then argv and lastly argc.  This is costly in stack space, it is
	true.  

	This has the additional benefit of letting the compilers know that
	other routines are NOT varargs, so they can generate better code for
	them.  In particular, they can pop the calling arguments off in the
	called routine.  On many machines this entails no additional instructions
	in the called routine, and at least one less per call.

	This is not a full answer, because on some machines, a pointer
	to one beast is a different length than a pointer to another. 
	Another layer of pointers and an argvv (argv squared ?) hurts too
	much to consider, but probably would work on those machines where
	all pointers to all the different pointers are the same size.

	All we've really done is suggest that it is impossible to create a
	programming language that is both complete and correct...
	That is, portable and usable.


	As long as I'm twiddling the semantics of the language, I'd like to
	propose "register" functions like these:

		static register int func (arg, arg2) {...}
		static register void func ....

	The purpose of the "register" (even for void !) is to prevent the
	programmer from taking the address of the function.  This allows
	the compiler to optimize function calls on some machines, where
	a near or short subroutine call could be used for those routines
	strictly local to the file, if the code size permits it.  On some
	machines, the called routine must do a short or long return, depending
	upon how it was called.  This works well together with the optimization
	mentioned above.

			teltone!warren