LLVMers,
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 ( ... )?
and
0e 07 00
Function returning Int ()
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. 
-- Robert.
Robert Mykland Voice: (831) 462-6725
And while we're on the subject to the type definitions table, what's the
difference between0e 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
Dear Chris,
I had a second question which is probably a dumb question, but here goes. 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?
-- Robert.
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