AIX still requires implicit extern C.
I previously have tried to disable the feature on AIX and it failed miserably.
Thanks, David
On Wed, Mar 21, 2018 at 8:15 AM, Nathan Sidwell <nat...@acm.org> wrote:
> 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
