|Compiling an ellipsis gcome@NOSPMcyberus.ca (Guillaume Comeau) (1999-11-21)|
|Re: Compiling an ellipsis firstname.lastname@example.org (Alan Donovan) (1999-11-23)|
|Re: Compiling an ellipsis email@example.com (Zalman Stern) (1999-11-23)|
|Re: Compiling an ellipsis firstname.lastname@example.org (James Jones) (1999-11-23)|
|From:||James Jones <email@example.com>|
|Date:||23 Nov 1999 00:41:17 -0500|
|Organization:||Microware Systems Corporation|
The answer to your question is: yes. Seriously, some compilers force
optional arguments onto the stack, and some go ahead and pass them as
if they were expected arguments (but performing the "usual argument
promotions"). One can argue that the latter is preferable for the
1. It covers up for programmers who sleaze out and forget to
include <stdio.h>--if the compiler does something special at
the call side, forgetting to have a prototype visible at the
call breaks things. (That's why the standard requires it.)
2. The parameter passing code is simplified, though just a little
bit, because you have to deal with passing parameters on the
3. The "pretend everything's normal' approach, in the implementations
I've seen at least, involve leaving space in the activation record
to dump all the parameters potentially passed in registers into
memory--the dumpage appears on the called function side. Depending
on the architecture, it may be easier/more efficient to do it all
at once and in just one spot.
All that said...what really does all this mess is the va_start(),
va_arg(), and va_end(); the *printf() calls just use those. Are you
targeting a compiler with a broken <stdarg.h>?
Guillaume Comeau wrote:
> Hence the question: are parameters in ellipsis forcefully on the
> operand stack, or can they be in internal registers as space allows?
> (in which I have some assembly work to do for each processor port).
Return to the
Search the comp.compilers archives again.