views:

488

answers:

4

Hi there.

I was wondering if there was any way to pass parameters dynamically to variadic functions. i.e. If I have a function

int some_function (int a, int b, ...){/*blah*/}

and I am accepting a bunch of values from the user, I want some way of passing those values into the function:

some_function (a,b, val1,val2,...,valn)

I don't want to write different versions of all these functions, but I suspect there is no other option?

A: 

It might be interesting to try just passing an array, and then use the vararg macros anyway. Depending on stack alignment, it might Just Work (tm).

This is probably not an optimal solution, I mainly posted it because I found the idea interesting. After trying it out, this approach worked on my linux x86, but not on x86-64 - it can probably be improved. This method will depend on stack alignment, struct alignment and probably more.

void varprint(int count, ...)
{
    va_list ap;
    int32_t i;

    va_start(ap, count);
    while(count-- ) {
     i = va_arg(ap, int32_t);
     printf("Argument: %d\n", i);
    }
    va_end(ap); 
}

struct intstack
{
    int32_t pos[99];
};

int main(int argc, char** argv)
{
    struct intstack *args = malloc(sizeof(struct intstack));
    args->pos[0] = 1;
    args->pos[1] = 2;
    args->pos[2] = 3;
    args->pos[3] = 4;
    args->pos[4] = 5;

    varprint(5, *args);
    return 0;
}
gnud
it won't work as arrays aren't passed by value, but as pointers
Christoph
True - when I thought it out, I thought of somehow pushing the array on the stack. But C won't do that if you just pass the array to a function - you would have to do it yourself.
gnud
When using a struct to wrap the array, it has the possibility of working, at least :) See example
gnud
+3  A: 

Variadic functions use a calling convention where the caller is responsible for popping the function parameters from the stack, so yes, it is possible to do this dynamically. It's not standardized in C, and normally would require some assembly to manually push the desired parameters, and invoke the variadic function correctly.

The cdecl calling convention requires that the arguments be pushed in the correct order, and after the call, the bytes pushed as arguments before the call are popped. In this way, the called function can receive an arbitrary number of parameters, as the caller will handle reverting the stack pointer to it's pre-call state. The space occupied by the arguments before the ... is the safe lower bound for number of bytes pushed. Additional variadic arguments are interpreted at runtime.

FFCALL is a library which provides wrappers for passing parameters dynamically to variadic functions. The group of functions you're interested in is avcall. Here's an example calling the functions you gave above:

#include <avcall.h>

av_alist argList;
int retVal;
av_start_int(argList, some_function, retval);
av_int(argList, a);
av_int(argList, b);
av_type(argList, val1);
...
av_type(argList, valn);
av_call(argList);

You might also find this link discussing generating wrappers around variadic functions in C, to be of interest in justifying why this isn't part of standard C.

Matt Joiner
@Anacrolix What do you mean "and invoke the varargs call appropriately."? The function deals with the varargs.
tommobh
@tommobh: i've edited to explain
Matt Joiner
@Anacrolix Thanks, much appreciated.
tommobh
+1  A: 

A standard approach is to have each variadic function accompanied by a va_list-taking counterpart (as in printf and vprintf). The variadic version just converts ... to a va_list (using macros from stdarg.h) and calls its va_list-taking sister, which does actual work.

atzz
Thanks, I'll look into this approach.
tommobh
@atzz Same problem though. I still need to add parameters dynamically to the function whether it calls its va_list-taking sister or not. Do you mean I convert the values to a va_list and then just use the va_list-taking sister function instead?
tommobh
@tommobh -- I guess i interpreted your question incorrectly. From reading the comments I take it that you have a means of obtaining values of different types (e.g. from gui) and need to pass them to a function; is it correct? In this case, va_list won't help much. If you don't want to rely on hacks, you'll have to change the functions...
atzz
A: 

Depending on what it is you're passing around, it could be a discriminated union you're after here (as hinted at in the comments). That would avoid the need for variadic functions or arrays of void*, and answers the question "*how does some_function know what you actually passed it*". You might have code something like this:

enum thing_code { INTEGER, DOUBLE, LONG };

struct thing
{
 enum thing_code code;
 union
 {
    int a;
    double b;
    long c;
 };
};

void some_function(size_t n_things, struct thing *things)
{
    /* ... for each thing ... */
    switch(things[i].code)
    {
      case INTEGER:
      /* ... */
    }
}

You can take this a step further and avoid the switch by replacing the code with one or more pointers to functions that do something useful with each thing. For example, if what you wanted to do was to simply print out each thing, you could have this:

struct thing
{
 void (*print)(struct thing*);
 union
 {
   ...
 };
}

void some_function(size_t n_things, struct thing *things)
{
  /* .. for each thing .. */
  things[i]->print(things[i]);
  /* ... */
}
Ned
@Ned: The variadic function I am using is in a library that I would ideally not like to change (i.e. i don't want to change 'some_function()'). The user can enter any amount of any type they like (within reason) so defining a strict union doesn't seem like it will work. An array of void* or Anacrolix's suggestion seems like my best bet. Either that or I write some inline assembly :S.
tommobh
But if you can't change some_function, how can you pass it an array of void*? By user here, are we talking about a developer using your code, or an end user of the program?
Ned
@Ned: User=end user. Yeah I see what you mean actually. I do not want to change the function because the function itself invokes another variadic function and I'd have to change that too. It would just snowball. I feel like I'm back where I started.
tommobh