Re: Compiling an ellipsis

James Jones <>
23 Nov 1999 00:41:17 -0500

          From comp.compilers

Related articles
Compiling an ellipsis (Guillaume Comeau) (1999-11-21)
Re: Compiling an ellipsis (Alan Donovan) (1999-11-23)
Re: Compiling an ellipsis (Zalman Stern) (1999-11-23)
Re: Compiling an ellipsis (James Jones) (1999-11-23)
| List of all articles for this month |

From: James Jones <>
Newsgroups: comp.compilers
Date: 23 Nov 1999 00:41:17 -0500
Organization: Microware Systems Corporation
References: 99-11-129
Keywords: C, code

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
following reasons:

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
      stack anyway.

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>?

James Jones

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

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.