In C++, do variadic functions (those with ... at the end of the parameter list) necessarily follow the __cdecl calling convention?

Question

I know that __stdcall functions can't have ellipses, but I want to be sure there are no platforms that support the stdarg.h functions for calling conventions other than __cdecl or __stdcall.

Allier

Answer 1

The calling convention has to be one where the caller clears the arguments from the stack (because the callee doesn't know what will be passed).

That doesn't necessarily correspond to what Microsoft calls "__cdecl" though. Just for example, on a SPARC, it'll normally pass the arguments in registers, because that's how the SPARC is designed to work -- its registers basically act as a call stack that gets spilled to main memory if the calls get deep enough that they won't fit into register anymore.

Though I'm less certain about it, I'd expect roughly the same on IA64 (Itanium) -- it also has a huge register set (a couple hundred if memory serves). If I'm not mistaken, it's a bit more permissive about how you use the registers, but I'd expect it to be used similarly at least a lot of the time.

Why does this matter to you? The point of using stdarg.h and its macros is to hide differences in calling convention from your code, so it can work with variable arguments portably.

Edit, based on comments: Okay, now I understand what you're doing (at least enough to improve the answer). Given that you already (apparently) have code to handle the variations in the default ABI, things are simpler. That only leaves the question of whether variadic functions always use the "default ABI", whatever that happens to be for the platform at hand. With "stdcall" and "default" as the only options, I think the answer to that is yes. Just for example, on Windows, wsprintf and wprintf break the rule of thumb, and uses cdecl calling convention instead of stdcall.

Anomalous

Your comment about SPARC applies to many if not all RISC architectures. Since the registers are so plentiful, the compiler just uses those to pass arguments. Not to mention, they're faster than memory by quite a bit, esp. since you're likely passing data that's already in registers (although I guess it'll need to push them onto the stack to restore them if it needs them later, but...). Anyway, I know that this is how it works on MIPS and I'm pretty certain that PPC works the same way. – Highwayman

"Why does this matter to you?" Ben is working on js-ctypes for Mozilla. You can see the exact context in bugzilla.mozilla.org/show_bug.cgi?id=554790 (search for "crazy idea") and you can some docs explaining js-ctypes at developer.mozilla.org/en/JavaScript_code_modules/ctypes.jsm – Archuleta

Needless to say, js-ctypes is only available to application code and add-ons, not web pages. – Archuleta

Currently we have a method for defining C functions from JavaScript, and that method has a parameter specifying the calling convention. I'm considering writing a version of that method for defining variadic C functions, and I wondered if it would need a similar parameter or not (in case the calling convention could just be inferred). – Allier

Not only must the caller be responsible for argument deallocation, the arguments must be pushed on the stack last-to-first. Otherwise it is impossible to access the first argument without knowing how many there are. For example, the pascal calling convention on Mac OS 68k is first-to-last, caller cleanup, this still isn't suitable for varargs. – Subsidy

@RustyX: While that is probably the most common way (at least on x86) there are alternatives--some pretty widely used, especially on machines like SPARCs, where you don't normally pass arguments (directly) on the stack at all. – Anomalous

Answer 2

The most definitive way that you can determine this is to analyze the calling conventions. For variadic functions to work, your calling convention needs a couple of attributes:

• The callee must be able to access the parameters that aren't part of the variable argument list from a fixed offset from the top of the stack. This requires that the compiler push the parameters onto the stack from right to left. (This includes such things as the first parameter to printf, the format specification. Also, the address of the variable argument list itself must also be derived from a known location.)
• The caller must be responsible for removing the parameters off the stack once the function has returned, because only the compiler, while generating the code for the caller, knows how many parameters were pushed onto the stack in the first place. The variadic function itself does not have this information.

stdcall won't work because the callee is responsible for popping parameters off the stack. In the old 16-bit Windows days, pascal wouldn't work because it pushed parameters onto the stack from left to right.

Of course, as the other answers have alluded to, many platforms don't give you any choice in terms of calling convention, making this question irrelevant for those ones.

Photoflood

Answer 3

Consider the following function on an x86 system:

void __stdcall something(char *, ...);

The function declares itself as __stdcall, which is a callee-clean convention. But a variadic function cannot be callee-clean since the callee does not know how many parameters were passed, so it doesn’t know how many it should clean.

The Microsoft Visual Studio C/C++ compiler resolves this conflict by silently converting the calling convention to __cdecl, which is the only supported variadic calling convention for functions that do not take a hidden this parameter.

Why does this conversion take place silently rather than generating a warning or error?

My guess is that it’s to make the compiler options /Gr (set default calling convention to __fastcall) and /Gz (set default calling convention to __stdcall) less annoying.

Automatic conversion of variadic functions to __cdecl means that you can just add the /Gr or /Gz command line switch to your compiler options, and everything will still compile and run (just with the new calling convention).

Another way of looking at this is not by thinking of the compiler as converting variadic __stdcall to __cdecl but rather by simply saying “for variadic functions, __stdcall is caller-clean.”

click here

Pubis

Answer 4

Do you mean 'platforms supported by MSVC" or as a general rule? Even if you confine yourself to the platforms supported by MSVC, you still have situations like IA64 and AMD64 where there is only "one" calling convention, and that calling convention is called __stdcall, but it's certainly not the same __stdcall you get on x86.

Picklock

Answer 5

AFAIK, the diversity of calling conventions is unique to DOS/Windows on x86. Most other platforms had compilers come with the OS and standardize the convention.

Mensuration