On Sat, Jun 16, 2012 at 3:54 AM, Duncan Sands <baldr...@free.fr> wrote: > Hi, > > >>> If ENABLE_BUILD_WITH_CXX is defined, then GCC itself is built with C++, >>> and we want a C++ signature for functions. If it is not defined, then >>> GCC itself is not built with C++, and we want (and must have) a C >>> signature. >>> >>> I suppose we would decide that fancy_abort always uses a C signature, >>> but that seems odd. >>> >>> Ian >> >> >> I guess the issue is when people care only about C plugins, yet >> fancy_abort >> get implicitly exported with a C++ linkage. >> >> I suspect this goes back to the eternal question: what do we consider as >> part of the public GCC public API (no, Basile, I am not suggesting to have >> the same discussion again.) > > > if the following are to hold > > (1) fancy_abort is declared in system.h > (2) system.h should not be wrapped in extern "C" when included from a > plugin, > (3) it should be valid to include it from plugins compiled as C or as C++, > (4) fancy_abort should use the same linkage as GCC, i.e. C when GCC built as > C, > C++ when built as C++ (aka ENABLE_BUILD_WITH_CXX). > > then something like the following seems inevitable: > > #ifdef ENABLE_BUILD_WITH_CXX > #ifdef __cplusplus > extern void fancy_abort(const char *, int, const char *) ATTRIBUTE_NORETURN; > #else > extern void _Z11fancy_abortPKciS0_(const char *, int, const char *) > ATTRIBUTE_NORETURN; > #endif > #else > #ifdef __cplusplus > extern "C" void fancy_abort(const char *, int, const char *) > ATTRIBUTE_NORETURN; > #else > extern void fancy_abort(const char *, int, const char *) ATTRIBUTE_NORETURN; > #endif > #endif > > That's pretty nasty. But to avoid the nastiness one of (1) - (4) needs to > be > dropped. Which one? > > Ciao, Duncan.
It is not just nasty; it is fragile. I think we should just give fancy_abort a C language specification.
