[LLVMdev] Seemingly ambiguous parameter lists

[Chris Lattner]

> I had a second question which is probably a dumb question, but here
> goes.

Not a problem.  :)

> I'm just wondering how a function that has all varargs knows what to do.
> I'm only familiar with the C style of varargs.  In that case you
> generally used one or more fixed parameters that told you how to
> interpret the rest.  Like the format string in printf, for example.  I
> suppose the function could look at a static variable somewhere to get
> this data.  That sounds messy.  Are these functions member functions
> with an implied first parameter perhaps?  If so, why not explicitly?

I assume you're talking about the va_start intrinsic:
http://llvm.cs.uiuc.edu/docs/LangRef.html#i_va_start

Basically here's the jist of it.  At least in C, it's impossible to make
use of varargs parameters in a function with zero declared arguments,
because the va_start macro requires the last argument as the parameter.
LLVM, however, is not necessarily tied down to C (we want to support
arbitrary languages), and adding the argument to va_start just makes
things needlessly more complex (what if the argument passed in is not the
last?)

The organization we have now allows us to put the error checking code in
the front-end for languages which do not allow this.  For a hypothetical
language which does allow varargs without a fixed, we support it just
fine.  :)

Essentially, these are the three reasons we don't have a restriction:

1. There MIGHT be some language that wants support for funny stuff like
   this.
2. It's easier to build the error checking into the C front-end, and then
   support the general case in LLVM.
3. Supporting the general case in LLVM is no harder than the "C" case.

Also, FWIW, it's very typical to define a varargs function with no
arguments in C.  In particular this function:

void foo();

Is varargs in C.  Contrast this with:

void foo(void);

And you are beginning to see a flavor of the fun stuff the C front-end has
to deal with.  :)  Of course, you can't USE the varargs in the body, so
the LLVM compiler transforms "void foo()" into "void foo(void)" when the
body is found, assuming it has no arguments.

-Chris


> At 04:17 PM 8/26/2003 -0500, Chris Lattner wrote:
> >On Tue, 26 Aug 2003, Robert Mykland wrote:
> > > And while we're on the subject to the type definitions table, what's the
> > > difference between
> > >
> > > 0e 07 01 00
> > > function returning Int ( Void )?  Function returning Int ( ... )?
> >
> >Void is not a legal argument.  The bytecode file uses the void marker as
> >a way to store the ... for a varargs function.  IE, the declaration:
> >
> >void foo(void);
> >
> >in C, becomes the LLVM type 'void ()*' %foo.  The C declaration:
> >
> >void foo(...);
> >
> >becomes the LLVM type 'void (...)*' %foo, which is stored in the bytecode
> >file (to be compact) as 'void (void)*'.
> >
> > > 0e 07 00
> > > Function returning Int ()
> >
> >That is just 'int ()', function returning int, with no arguments.
> >
> > > I'm guessing the former really is a function returning Int ( ... ), but how
> > > is the callee supposed to decode the parameter list?  I'm an old callee and
> > > I don't know this new trick.  :-)
> >
> >Void is not a legal argument type, it is just used as a marker in the
> >bytecode files.  :)
> >
> >-Chris
> >
> >--
> >http://llvm.cs.uiuc.edu/
> >http://www.nondot.org/~sabre/Projects/
>
> Robert Mykland     Voice: (831) 462-6725
>

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/