Why GCC and Clang Defy Standard C++ Rules on Function Linkage
Neither GCC nor Clang are compliant with standard C++
I discovered that GCC and Clang ignore the C++ standard's rule that function types with different language linkages must be distinct. This oversight causes type mismatches and compilation errors where none should exist. I argue the standard is flawed, not the compilers, since changing their behavior would break the ABI while C and C++ calling conventions are identical on most platforms.
IMO the blame here doesn't lie on GCC or Clang; it lies on the standard.
- kloop
Give how default gcc and clang are, along with the recommendation to update the standard instead of gcc and clang, it sounds like the standard is noncompliant with standard C++
Standard in the sense of commonly used or supplied
- jdw64
But looking at this, it seems like something similar happened 12 years ago[1]. Why hasn't it been changed?
- Fudgel
- dataflow
> gcc and clang can't change their behavior because that would be a breaking ABI change
It's an API change. Breaking source code is generally an even bigger deal than breaking binary compatibility.
- rurban
It's about language *linkages*, not about extern "C" vs C++ linkage.
It's about stdcall, cdecl, fastcall, vectorcall, watcall, and other calling conventions, which should be in the type. And they are.