[Bug c++/53673] Add magic weak symbol to indicate C++ standard setting (C++03, C++11 etc) to help debug ABI problems

["s_gccbugzilla at nedprod dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53673

--- Comment #6 from Niall Douglas <s_gccbugzilla at nedprod dot com> 2012-06-15 16:53:01 UTC ---
(In reply to comment #5)
> > They don't have any ABI impact that we know of at the present time in this
> > present generation of GCCs. As a debug aid that's likely to be there from now
> > on and forever, who's to say about the future.
> 
> The GCC maintainers are to say.

It's safer to fail safe. And no maintainer is omniscient.

> > Better to cover all bases now
> > I'd say, just in case.
> 
> There's no point adding (and maintaining) yet another feature to handle
> hypothetical differences which *by*design* should not happen.

There's the ideal world and there's the real world. This is a very likely
ongoing real world problem whose fix requires perhaps five lines of new code -
hardly a big new feature requiring umpteen lines of code. I'd write the patch
myself except I'd put those five lines in the wrong place because GCC's code
base is so monolithic.

Technically, you could add it to the top of <stddef.h> or whatever is a
guaranteed included library header:

#if defined(__cpluscplus) and __cplusplus==201103L
extern "C" void __gplusplus_std_cplusplus11() __attribute__ ((weak));
#elif defined(__cpluscplus) and __cplusplus==199711L
extern "C" void __gplusplus_std_cplusplus97() __attribute__ ((weak));
#elif ...
#else
#error Unknown C++ variant, cannot set magic symbol
#endif

... assuming that compiles which I can't test on this laptop.

> Far more relevant than c++11 vs gnu++11 is -fabi-version=n, which your scheme
> doesn't cover.

ABI is a GCC issue :). I'd certainly recommend it for that too. You may need to
bump ABI if needed to solve C++11 and C++03 interop and a way for checking for
that would also be useful.

> > There are no shortage of third party libraries which enable special new stuff
> > when compiled with GNU additions turned on.
> 
> Not GCC's problem, and no different to libraries which enable new things when
> -fno-rtti or -fno-exceptions is used

Look, it's a debug aid, and if GCC offers special extra features then it's
GCC's problem if libraries use them. In the future GCC is going to see lots of
C++11 "bugs" submitted. You're going to ask the question "are you *really* sure
you compiled everything with C++11?". Right now they'll say yes, but they may
well be wrong. This debug aid is as much for your future sanity as anything.

> > Also, the ISO C++ standard is quite clear that ABI between C++03 and C++11
> > compiled code is not guaranteed in the case where C++11 libraries/shared
> > objects are linked into a C++03 compiled program. Indeed, really an error ought
> > to be thrown if this happens for safety's sake, a warning as a minimum.
> 
> [citation needed]  ;)

:) ... I don't suppose you'd take my word as ISO SC22 convenor for Ireland
would you? ;)

No, it's fair enough, I only know that from watching the discussions on ISO and
I have no idea if it's actually written in the final published standard. It is
however written in Nicolai Josuttis' updated C++11 "The C++ standard library"
in the chapter on C++11 core language changes. And if you think it through,
there has to be in practice ABI breakage in 03 ABIs because no one could have
anticipated during their design of what 11 would require [1].

[1]: This may not apply to GCC as it revised its ABI quite recently, and I'm
sure its designers took into account likely future 11 requirements.

> The standard says nothing about "libraries/shared objects"

I know only too well. I have an early draft for shared library implementation
on my desk for WG14. It's too ambitious for WG14 as it explicitly adds interop
for non-C languages.

> It's entirely possible to use G++ to build 100% ABI compatible applications
> using a mixture of -std=c++98 and -std=c++11 objects, if you don't use the
> parts of the standard library that are incompatible.  A mandatory or warning
> would cause problems for anyone doing that.

Sure. Any C++ implementation may choose to go beyond what is needed. However, I
personally can see lots of potential for monsters to lurk there. I think the
proposed debug aid will save a lot of time for a lot of people in the long run,
and for the cost of implementation and almost nil cost of maintenance I'd just
go ahead and implement it if I were ye. Which I'm not, so all I can do is try
to persuade and advocate.

Niall