[pjmlp]

Compiler and OS vendors. The same behind undefined behavior.

Although people like to bash C++, there isn't any programming language with an ABI as part of the language standard, not even C.

The C ABI that so many people adhere to, only exists in OS written either in C or C++ (via extern "C").

By the historical accident that all commercial major OSes are mostly written in C, developers that aren't language lawyers tend to think C ABI is somehow defined in some standard.

In OSes that weren't written C, with C compilers available, like OS/400, VMS, Lillith, Lisp Machines, Oberon, the ABI being used isn't the C one.

[geofft]

Yes, the C ABI / calling convention is OS- and platform-specific. (Which does lead to practical problems on modern systems when you assume the ABI behaves similarly on different platforms; a good example is https://github.com/rust-lang/rust/pull/22862 , caused by 64-bit iOS treating varargs differently from OS X on x86-64 or even Linux on aarch64.)

However, within a given platform, the ABI tends to be small, clear, and well-documented. It's not documented in the C language standard, but there is documentation for it, from whoever defines the platform.

I thought I had mentioned this in another comment, but to be clear, I'm not trying to "bash C++"; plenty of other type systems and standard libraries have the same issue (including Go, Rust, Python, etc.). I'm just relaying the fact that, on the platforms where Go and Rust support FFI, they do so by implementing the C ABI, which is a stable ABI defined in the platform documentation, and the C++ ABI tends not to be well-defined or stable and is also much more complex to implement. This isn't a criticism of C++, just a fact. (And there are good things about this; for instance, C++'s type system is so much more useful than C's.)

[pjmlp]

Fair enough, my reaction was more to those that bash C++ without recognition that the issue is not C++ specific.