#c variadic functions

[mentalisttraceur-software]

Variadic Functions in C

A Nicer Approach

So I've described the problem, and even why it maybe makes sense for that problem to exist at the low level of the language definition, but we can do better for actual humans writing C.

As of C99, we have variadic macros, and we have compound literals. This means that we can wrap variadic functions in macros that automate two common conventions for variadic functions:

pass a magic end-of-arguments value, or

pass the number of variadic parameters.

Let's take a function like `execl` for example: it takes some number of `char *`, and it expects the last one to be a null pointer. Behold:

#define EXECL(...) execl(__VA_ARGS__, (char * )0)

Boom. Problem solved. No more segfaults or stack corruptions or exploitable code execution vulnerabilities in your code just because you forgot to put a null pointer at the end, or forgot to cast it to the a pointer type with a compatible representation.

Now how do you count arguments? Well, if your arguments are all of the same type, or implicitly convertible to the same type, you can throw them into a compound literal for an array of that type and take the size of that array:

#define ARGUMENT_COUNT(type, ...) (sizeof((type[]){__VA_ARGS__}) / sizeof(type))

So then if you have a function like this:

int sum(size_t argument_count, ...)

You can wrap it like this:

#define SUM(...) sum(ARGUMENT_COUNT(int, __VA_ARGS__), __VA_ARGS__)

Same benefit: the function receives an automatically computed-at-compile-time first argument of how many parameters the wrapper macro call received. And since the stuff inside a `sizeof` operator is not evaluated - only the type of the expression is statically figured out per compile-time C rules - you don't get any of the problems with macros evaluating their arguments multiple times.

[mentalisttraceur-software]

Wrote another rendition of my nicer type-safe variadic functions in C post, as a StackOverflow answer. Maybe I should roll this idea into a nicer-variadics.h and throw it up on GitHub?

[mentalisttraceur-software]

Variadic Functions in C

A Nicer, Type-Safe Approach

(Building on the previous post.)

Type-safety is lost with variadic functions in C, because the arguments for `...` can be of any type, and worse, they undergo implicit conversions that could be the source of subtle bugs.

It is only in rare situations that we want to actually take any type of arguments. Usually we know much more specifically what type of arguments we want. Even the `printf` and `scanf` interfaces can't take any type - they have no idea what to do with arbitrary unions or structs for example.

So in cases where you know it's supposed to be a specific type, or one of a few known types (a single union type!), you can use an array instead of `...`. That's well-known, but then we have to explicitly pass the array size and wrap what would be just arguments in a function call into an array first. Unless you combine it with the trick from the last post - then you can remove all of those downsides. For example, instead of

int sum(size_t count_of_integers, ...)

you could do

int sum(size_t count_of_integers, int * integers)

and then use an array compound literal to turn an argument list into an in-place array literal:

#define SUM(...) sum(ARGUMENT_COUNT(int, __VA_ARGS__), (int[]){__VA_ARGS__})

The main advantage is that you have all the ergonomics/convenience of a variadic function at the source level, but the compiler will now tell you if one of your arguments doesn't match the type of arguments that the "variadic" function expects, in this case `int`..

This of course generalizes to the end-of-arguments value approach as well, you just have to put that termination value into the array itself. An example wrapping `execv`, similarly to how `execl` was wrapped in my last post:

#define EXECV(program, ...) execv(program, (char * [] ){__VA_ARGS__, 0})

Of course "truly" variadic C functions (ones with `...` in the parameter list) and these pointer-to-array pseudo-variadic functions will usually have different ABIs. But that's actually a good thing. The array ones are often nicer to interface with from other programming languages, and lend themselves better to uses where the argument list varies programmatically.

[mentalisttraceur-software]

Variadic Functions in C

The Rationale

It makes sense to me that C was standardized with the problem of variadic functions not being told how many arguments they get.

In order for the compiler to give your function the information about how many arguments it received, the language would have to either assume and impose a specific convention for passing that information, or add complexity so that the source code could express the best way for it to receive that information.

But different functions might benefit from different conventions. Even if some of those conventions are later discovered to be only the best fit for solutions that are strictly inferior to other alternatives, that might take a long time to figure out. And back when C was being standardized, paying extra overhead for stuff that wasn't the best fit for your problem probably reasonably seemed like an unacceptable cost. I'm sure there are still hot code paths where that's true to this day.

So I get why C's variadic functions are limited and un-ergonomic at the language level like that.

[mentalisttraceur-software]

Variadic Functions in C

The Problem

In C, the caller can't just pass any number of arguments to a variadic function, they also have to repeat themselves by passing an argument which redundantly encodes how many arguments there are. It might be encoded as the number of format specifiers in a string, directly passed as a number, implied by a magic end-of-arguments argument value like a null pointer, or whatever.

At the machine level, this is not redundant, because no information is free: how does your function's code know where in the computer to look for arguments? how does it know when there are no more arguments? that information is either hard-coded into the code of the function itself, or it is somehow passed to the function in a way that the function is hard-coded to interpret.

But at the human and source-code level, it is redundant: we know how many arguments a function is being given because that is how many arguments are written in the function call. That information is available statically, at compile-time! But C does not give that information to our code.