C++ ABI standards compliance w/ arbitrary name mangling [closed]

Question

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.

Closed 8 years ago.

Okay, the question title was kind of a hook. I already get that there is no C++ standard ABI. That said, I've not deceived you eager upvote-gatherers. I'm wondering if there is ANY limitation to the C++ ABI. It seems common, for example, for at least the name of a class to be mangled somewhere in the ABI name.

A more explicit question

Let's say I have a collision-free hash function over all strings. Let's then say GCC added one more step to its name mangling: appending the hash of the current mangled name to an underscore. This would break almost everything under the sun, but would GCC still be as C++ standards conforming as it was before?

EDIT:

Okay, apparently the 'explicit question' bit was kind of a poorly chosen subsection name. I really wanted to know more about any common ABI standards that people follow. This was informed by the existence of binaries I have being compiled with Mingw32 linking successfully with binaries I have being compiled with MSVC.

Answer 1

It would still conform to the ISO C++ standard, which doesn't even mention name mangling in normative text let alone restrict how it can be done, but would not conform to the cross-vendor ABI standard that GCC uses for most platforms.

Answer 2

The Standard is quite silent on this matter, on purpose: all that relates to ABI and name mangling is implementation specific. The closest thing to an information on the subject is, I believe:

7.5/1 [dcl.link]

All function types, function names with external linkage, and variable names with external linkage have a language linkage. [ Note: Some of the properties associated with an entity with language linkage are specific to each implementation and are not described here. For example, a particular language linkage may be associated with a particular form of representing names of objects and functions with external linkage, or with a particular calling convention, etc. — end note ]

As such, each implementation is free to do anything it wants concerning name mangling as long as the mangled names are valid on the underlying OS.

Answer 3

Yes, it would of course still be just as standards compliant. However, as awesome as it is to be standards compliant, it is certainly not the be all and end all.

Such a change would literally break backwards compatibility for every single library or application written in C++ and compiled using said version of GCC. Backwards compatibility is incredibly important to the GCC developers, and they spend quite some time on the mailing lists (just look) discussing the relative benefit of even incredibly minor ABI changes in the face of such breakage. Oftentimes they will go to considerable lengths to offer workarounds that can preserve backwards compatibility.

Something tells me that most distros would refuse to upgrade if they changed this policy. Might get a bunch of them to move to clang even...

At least we could rest assured that they would add yet another -f option that would switch off the new 'feature'.