Excerpts from the mail message of Abhijit Menon-Sen:
)
) At 2001-10-24 07:39:45, [EMAIL PROTECTED] wrote:
) >
) > Is it possible to code a homegrown va_list (that my vararg C function
) > will accept) in the perl XS code (without using the stdarg.h macros
) > that are giving me compilation problems)?
)
) No.
)
) A C function with a "..." prototype may be called with a varying number
) of arguments on the stack. It is left to the compiler to retrieve these
) arguments and compose them into va_lists (and different compilers do it
) differently).
)
) In contrast, an XS function with a "..." prototype may be called with a
) varying number of arguments on the Perl argument stack, but it is still
) called only with a fixed number of arguments on the system stack. (Have
) a look at the .c file which xsubpp generates.) This is why the va_list
) approach didn't work in your code.
)
) There is no nice way to compose va_lists by hand. Sorry.
Actually, I suspect that a majority of platforms will let you do
something horribly hackish like:
char *stack= malloc( (2*count+1) * sizeof(double) );
va_list list;
va_start( list, (stack[count*sizeof(double)]) );
for( i= 0; i < count; i++ ) {
va_arg( list, double )= numbers[i];
}
va_end( list );
va_start( list, (stack[count*sizeof(double)]) );
v_api( list );
va_end( list );
The trick with va_*() is that you don't know whether it is going
to move "up" or "down" your stack and you don't know what rules
it uses to adjust the "size" of arguments. For example, one common
rule is that arguments of type "char" still take up 4 bytes.
But you are lucky in that va_arg(list,DataType) usually expands
out to be
*(DataType *)( some address calculation )
which means that you can assign _to_ it as well as assign _from_
it.
But don't tell anyone that you got this from me. And there are
probably platforms out there will something like this won't work,
but I don't think I've personally run into any of those.
Tye
