The function signature is a lie

21 hours ago

A function signature represents a source-level API, but the underlying ABI (Application Binary Interface) defines the actual binary protocol for function calls, including hidden arguments like result pointers.
ABIs involve hidden parameters such as indirect result storage for large return types, which can shift visible arguments and vary across platforms (e.g., Windows x64, System V AMD64, AAPCS64).
Non-static member functions include a hidden object pointer, which may require adjustment for inheritance and virtual dispatch, adding complexity beyond the visible argument list.
Variadic functions (e.g., printf) require extra ABI considerations like register duplication or hidden markers (e.g., AL in System V AMD64), making FFI (Foreign Function Interface) more treacherous.
ABIs encompass more than calling conventions; they include type layout, stack rules, unwind metadata, and other low-level details essential for interoperability and debugging.
ABI bugs often manifest delayed failures, such as incorrect unwinding or crashes in tools like profilers, due to violations of the binary protocol at call boundaries.
Understanding the ABI boundary is crucial for cross-compilation scenarios like dynamic libraries, JIT stubs, plugins, and language interop, where independent code must agree on the protocol.

Hasty Briefsbeta