The C and C++ standard do not have any requirement on how it has to work. A complying compiler may well decide to emit chained lists, std::stack<boost::any>
or even magical pony dust (as per @Xeo's comment) under the hood.
However, it is usually implemented as follows, even though transformations like inlining or passing arguments in the CPU registers may not leave anything of the discussed code.
Please also note that this answer specifically describes a downwards growing stack in the visuals below; also, this answer is a simplification just to demonstrate the scheme (please see https://en.wikipedia.org/wiki/Stack_frame).
How can a function be called with a non-fixed number of arguments
This is possible because the underlying machine architecture has a so-called "stack" for every thread. The stack is used to pass arguments to functions. For example, when you have:
foobar("%d%d%d", 3,2,1);
Then this compiles to an assembler code like this (exemplary and schematically, actual code might look different); note that the arguments are passed from right to left:
push 1
push 2
push 3
push "%d%d%d"
call foobar
Those push-operations fill up the stack:
[] // empty stack
-------------------------------
push 1: [1]
-------------------------------
push 2: [1]
[2]
-------------------------------
push 3: [1]
[2]
[3] // there is now 1, 2, 3 in the stack
-------------------------------
push "%d%d%d":[1]
[2]
[3]
["%d%d%d"]
-------------------------------
call foobar ... // foobar uses the same stack!
The bottom stack element is called the "Top of Stack", often abbreviated "TOS".
The foobar
function would now access the stack, beginning at the TOS, i.e. the format string, which as you remember was pushed last. Imagine stack
is your stack pointer , stack[0]
is the value at the TOS, stack[1]
is one above the TOS, and so forth:
format_string <- stack[0]
... and then parses the format-string. While parsing, it recognozies the %d
-tokens, and for each, loads one more value from the stack:
format_string <- stack[0]
offset <- 1
while (parsing):
token = tokenize_one_more(format_string)
if (needs_integer (token)):
value <- stack[offset]
offset = offset + 1
...
This is of course a very incomplete pseudo-code that demonstrates how the function has to rely on the arguments passed to find out how much it has to load and remove from the stack.
Security
This reliance on user-provided arguments is also one of the biggest security issues present (see https://cwe.mitre.org/top25/). Users may easily use a variadic function wrongly, either because they did not read the documentation, or forgot to adjust the format string or argument list, or because they are plain evil, or whatever. See also Format String Attack.
C Implementation
In C and C++, variadic functions are used together with the va_list
interface. While the pushing onto the stack is intrinsic to those languages (in K+R C you could even forward-declare a function without stating its arguments, but still call it with any number and kind arguments), reading from such an unknown argument list is interfaced through the va_...
-macros and va_list
-type, which basically abstracts the low-level stack-frame access.