News for hackers. Stuff that matters.
Re:OS X app in plain C by poizan42 on Thursday May 05, 2016 @04:20PM (#11639373)
At least MSVC on x86 uses "thiscall" by default which puts the this pointer in ecx. You cannot call those functions from C without specific compiler support.
Re:OS X app in plain C by vardump on Thursday May 05, 2016 @06:39PM (#11640219)
Sure you can.

Just write an asm stub to call, that sets up ecx and other things right.

Re:OS X app in plain C by poizan42 on Thursday May 05, 2016 @08:33PM (#11640823)
The claim was: The same goes for C++ or Swift. Getting the function pointer for a method can be involved, but all functions adhere to the C ABI.

This is clearly false since at least one C++ compiler generates functions that does not adhere to any of the common calling conventions for C on that platform (or "C ABIs" if you will).

Besides that, I said you could not call them from C. An asm stub is not C. Neither is inline assembly even though it's a common extension to C.

Re:OS X app in plain C by jheriko on Thursday May 05, 2016 @07:27PM (#11640498)
thats not true if you inspect the details of the specific ABI and cheat a little or use some inline assembler... but cl is easily the worst compiler for a C++ ABI.

they break it on tiny incremental updates sometimes... at least historically (in fairly recent history at least).

Re:OS X app in plain C by poizan42 on Thursday May 05, 2016 @08:43PM (#11640864)
> thats not true if you inspect the details of the specific ABI and cheat a little or use some inline assembler...

Some x86 C compilers supports calling conventions that lets you put things in registers, e.g. Microsofts "fastcall". But I wouldn't consider that part of the standard "C ABI" for Windows given that it's practically never used for externally visible functions. As I said "without specfic compiler support".

Using inline assembler is just cheating, it's not C.

> but cl is easily the worst compiler for a C++ ABI. they break it on tiny incremental updates sometimes... at least historically (in fairly recent history at least).

That is more about name mangling schemes and layout of standard library classes though. As far as I know the calling conventions has been quite fixed for a long time.