3 ms·
its a shame this only glosses over the subject, and starts with a highly misleading example and then continues with plenty more misleading information. unix/wi
by jheriko 10y ago
its a shame this only glosses over the subject, and starts with a highly misleading example and then continues with plenty more misleading information.
unix/windows are not interchangeable with compilers targetting those platforms. the article doesn't make the distinction or highlight why it matters - the OS has nothing to do with calling conventions in this context, they are just very conveniently the same in this case.
this example doesn't work with vs2010 out of the box because it targets win32 by default... for example. its the compilers, and only the compilers, which are deciding this. the standard calling convention for the platform is incidental, and it being identical to the default for the compiler is a wise design choice for compilers targetting x64, rather than a necessity - something which is much clearer in the old world of windows and x86 (32-bit) where cdecl was the default out of the box, and stdcall was what windows api calls expected.
- cbr 10y agoDoesn't the compiler at least need to use the platform-standard argument convention when calling OS functions?
- inlined 10y agoYes. Every Windows API is prefixed with WINAPI, which is a macro for the calling convention.
- int_19h 10y agoThe macro expands to nothing on Win64, though, because it has one standard calling convention. (At the ABI boundary, anyway. There's also __vectorcall now. And, of course, the compiler can use whatever it wants for functions that are not exposed at the boundary - even arbitrary register assignments based on where the function is actually called, to minimize the amount of work needed to save registers etc.)