-1

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.

user
  • 4,920
  • 3
  • 25
  • 38
  • 2
    You've answered your questions yourself in the second sentence - *there is no C++ standard ABI*. Once that's established, is there a need to answer whether there is a limitation to how the ABI is managed? Without any standard, why would name mangling that includes hashes, or whatever else, be any more or less conforming than any other implementation? – Praetorian Jun 14 '13 at 22:06
  • I would say that yes, GCC would still be C++-standards-conforming. It is an interesting question for me though. I'd imagine that the C ABI and OS loader rules does place some constraints on the C++ ABI, because C++ modules need to be able to masquerade as normal (C) modules for the OS loader. Note that I'm not talking about `extern "C"` here; I'm saying that C++ modules need to be loadable by the same OS loader like most everything else, and that loader mostly understands the C ABI (give or take.) – yzt Jun 14 '13 at 22:07
  • @yzt There is no requirement in the standard that operating systems must use a C ABI. (Some don't.) All that the standard requires is that the implementation be able to run conforming programs. The implementation is free to choose an operating system where the native ABI is C++. – Raymond Chen Jun 14 '13 at 22:15
  • @RaymondChen: Well, I was saying that from a practical point of view, since I imaging that most OSes use an approximation of the C ABI. But thanks for pointing that out! (Delighted to meet you, by the way, sir! Long time follower!) – yzt Jun 14 '13 at 22:26
  • 1
    @yzt True, but this question was a language-lawyer question, not a practical one. (The OP admitted that it was impractical. "This would break almost everything under the sun.") As such, I've flagged it as off topic (not practical). – Raymond Chen Jun 14 '13 at 23:23
  • @RaymondChen I think I should've been more clear to the intention of the question, then. I was hoping that someone would point out any existent standards that the compilers *do* follow, because I clearly have binaries compiled in Mingw32 and by MSVC and they can *link to each other*. I wanted this for the slightly more practical purpose of checking substrings of mangled names if some more common non-C++ standard *did* exist. As such, Jonathan Wakely's answer is about to be the accepted one. I'll edit the question to make that intention more clear. – user Jun 15 '13 at 04:43
  • And I just noticed that the title was also probably more directed toward the impractical question than the ABI standards bit. I'll try to be a little more careful with my wording next time. Sorry 'bout that. – user Jun 15 '13 at 04:49
  • If you wanted to know what (official or de facto) ABI standard GCC uses then you should have simply asked that, instead of asking if there's any limitation on what compilers do, and asking a hypothetical question about an alternative mangling scheme. – Jonathan Wakely Jun 15 '13 at 12:00
  • Ming32 and MSVC can link together not because of any common standard but because the Mingw32 folks [copied MSVC but didn't get it perfect](http://www.mingw.org/wiki/Interoperability_of_Libraries_Created_by_Different_Compiler_Brands). Indeed, different versions of MSVC are not even compatible with each other! – Raymond Chen Jun 15 '13 at 14:06
  • @JonathanWakely Weird headspace when I was asking the question. Again, apologies. – user Jun 16 '13 at 01:21

3 Answers3

5

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.

Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
4

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.

syam
  • 14,701
  • 3
  • 41
  • 65
  • 1
    Implementation _specific_ not implementation-defined, the latter would mean implementations are required to document their mangling scheme etc. which is not the case – Jonathan Wakely Jun 15 '13 at 00:15
  • You're right. And it's even the wording used in the paragraph I quoted, so I have no excuse. :) – syam Jun 15 '13 at 00:24
0

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'.

Robert Mason
  • 3,949
  • 3
  • 31
  • 44