Isn't this an OS issue rather than a general port issue. Seems to me it
will depend on the system header files. With a few notable exceptions
I'm not sure the port maintainers can answer this for all their target OSs.
R.
On 21/03/18 12:15, Nathan Sidwell 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
