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
