This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Deprecate not defining NO_IMPLICIT_EXTERN_C
- From: Nathan Sidwell <nathan at acm dot org>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>
- Cc: Richard Earnshaw <Richard dot Earnshaw at arm dot com>, rth at twiddle dot net, gnu at amylaar dot uk, Nick Clifton <nickc at redhat dot com>, chertykov at gmail dot com, jzhang918 at gmail dot com, Bernd Schmidt <bernds_cb1 at t-online dot de>, hp at axis dot com, james dot bowman at ftdichip dot com, Jeff Law <law at redhat dot com>, Jan Hubicka <hubicka at ucw dot cz>, Jim Wilson <wilson at tuliptree dot org>, sebastien at milkymist dot org, eager at eagercon dot com, clm at codesourcery dot com, green at moxielogic dot com, jasonwucj at gmail dot com, cltang at codesourcery dot com, tom at codesourcery dot com, ni1d at arrl dot net, kito dot cheng at gmail dot com, dj at redhat dot com, David Edelsohn <dje dot gcc at gmail dot com>, hepenner at us dot ibm dot com, Alexandre Oliva <aoliva at redhat dot com>, davem at redhat dot com, walt at tilera dot com, matt at 3am-software dot com, ebotcazou at libertysurf dot fr, augustine dot sterling at gmail dot com
- Date: Wed, 21 Mar 2018 08:15:44 -0400
- Subject: Deprecate not defining NO_IMPLICIT_EXTERN_C
Port maintainers CC'd, apologies if I've missed you.
NO_IMPLICIT_EXTERN_C is a target machine define that turns off wrapping
system header files in 'extern "C" { ... }'. It is the remaining
non-deprecated ARM-era compatibility behaviour. Can we deprecated it?
Unfortunately it's a negative-sense define, that now at least most ports
define. Do all ports define it? It's hard to determine that, because
many ports get it set via config/gnu-user.h or similar common file.
It also has the following undocumented features (when not set):
1) in a system header in an extern "C" region, a prototype of the form
'T func ()' means unspecified parms. We treat it as (...), but that's
not valid C and probably will do the wrong thing with today's more
complex ABIs.
2) Again, in a system header for extern "C" fns, enables matching
between function prototypes via self-promoting parameter types. I.e.
'extern "C" T foo (char)' and 'extern "C" T foo (int)' are the same fn.
The path by which the extern "C" wrapping happens is tortuous though
c-family/c-lex.c via a global variable and the parser setting flags on
each token. Ugh!
I think the way of going about that would be to require it to be defined
to either 0 or 1, and test that, rather than its definedness. Then any
ports that require the old behaviour will need to set it to zero,
explicitly indicating the requirement. Something like:
// in default.h
#if !defined (NO_IMPLICIT_EXTERN_C) \
|| (0 - NO_IMPLICIT_EXTERN_C - 1) > 0 /* Detect blank */
#error NO_IMPLICIT_EXTERN_C must be defined to 0 or 1, see XXX
#endif
modify the existing #defines to provide a value.
modify the uses from
#ifndef NO_IMPLICIT_EXTERN_C
into
#if !NO_IMPLICIT_EXTERN_C
(That's just as vulnerable to misspellings of the name as the ifndef
case, and we're converting existing code, so probably quite safe.)
My suspicion is that pdp11 and/or vax may care?
Comments/Objections?
nathan
--
Nathan Sidwell