@saramg@fosstodon.orgC: I am the best language, C++ is too obsessed with types.
Also C:
void foo(int a, float b) {
printf("%d -> %f\n", a, b);
}
typedef void(*fn)(float, int);
int main(void) {
fn bar = (fb)foo;
bar(3.1415, 42);
return 0;
}
// outputs: 42 -> 3.1415
C++: Who hurt you, man?
@saramg the funny thing is that this will only work if you compile for 64-bit x86. If you use 32-bit you'll get something different.
Other architectures will behave differently of course. I'm only referring to x86 here.
@saramg@fosstodon.org@loke On a system with an FPU it should still be the same on (modern/non-esoteric) 32bit, though certainly if you have no FP registers it won't. I made sure to reference int/float to sidestep this potential issue. God know it's cursed and should not be relies upon. :D
But fair, I'm mainly speaking from a 64bit pov because it's 2023 and I like to ignore embedded systems. :)
@saramg The 32-bit ABI passes all arguments on the stack, which means that calling order will be applied.
The reason you see the behaviour above is because the 64-bit ABI passes arguments in registers, and floating point and integer values are passed in different registers.
Now, I'm talking specifically about the Linux 32-bit ABI. Windows may be different.
@saramg@fosstodon.org@loke I know tgat Windows 32 bit uses edi, esi, edx, ecx, then stack.
I thought that Linux was similar, but I'll admit it's been awhile since I gave 32bit much thought.
@saramg@fosstodon.org@loke Nevermind wikipedia says I must've been doing too many drugs back then. https://en.m.wikipedia.org/wiki/X86_calling_conventions