Hacker News Reader

Comment by jckarter | Hacker News Reader

This is incorrect. It's not possible to implicitly use an incompatible ABI for prototyped and vararg functions, since a foo f(bar, bas) function needs to be callable via an unprototyped foo (* )() pointer. Thus, even prototyped C functions need to use a caller-cleanup convention. To use the callee-cleanup convention, the entire Win16 and Win32 apis are annotated with explicit __stdcall attributes and are addressed by distinctly-typed (__stdcall * ) function pointers, of which no vararg variation is allowed.

View on HN

I really wish this were true since it would solve my original problem, but after reading the standard I don't think this is true. From c99, 6.5.2.2 p6:

"If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double. These are called the default argument promotions. If the number of arguments does not equal the number of parameters, the behavior is undefined."

I take the last sentence to mean that an unprototyped function pointer may only be used to call a function that takes zero parameters.

That's not what it says. The last statement is talking about what happens at runtime (i.e. the number of values on the stack vs. the number expected, not the number of values passed vs. declared).

Obviously if you don't pass the right number of parameters, the function behavior is undefined (i.e. a pascal function will of course muck up the stack)

The language in the standard may have changed in C99 due to unprototyped functions being deprecated. In C89, however, I'm pretty sure that unprototyped and prototyped functions need to have compatible calling conventions. In practice, there's no platform I know of where a prototyped function cannot be called as a variadic or unprototyped function (barring special platform-specific ABIs like stdcall that weren't designed for C). Some RISC-style ABIs with pass-by-register and shadow space will fail in the reverse case (a variadic function called as a fully prototyped function) since the shadow space doesn't get populated by the caller for a fully prototyped function, but for a variadic call site, both the shadow space and parameter registers will be populated, specifically to allow prototyped functions to be called as unprototyped.

Reply on news.ycombinator.com