Deprecate not defining NO_IMPLICIT_EXTERN_C

Deprecate not defining NO_IMPLICIT_EXTERN_C

[Nathan Sidwell]

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

Re: Deprecate not defining NO_IMPLICIT_EXTERN_C

[Richard Earnshaw (lists)]

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

Re: Deprecate not defining NO_IMPLICIT_EXTERN_C

[David Edelsohn]

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 <nathan@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

Re: Deprecate not defining NO_IMPLICIT_EXTERN_C

[Nathan Sidwell]

On 03/21/2018 10:18 AM, David Edelsohn wrote:
> AIX still requires implicit extern C.
> 
> I previously have tried to disable the feature on AIX and it failed miserably.

That's unfortunate :(

nathan

-- 
Nathan Sidwell

Re: Deprecate not defining NO_IMPLICIT_EXTERN_C

[Joseph Myers]

On Wed, 21 Mar 2018, Nathan Sidwell wrote:

> 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.

Bare-metal ports often fail to define it.

As far as I know, newlib headers at least do not require implicit extern 
C.  If there are any that are missing explicit extern C, I'd rather that 
was addressed by (a) fixing them and (b) adding fixes in fixincludes if we 
wish to work with older header versions.

My list from 2005 of targets not defining NO_IMPLICIT_EXTERN_C then is 
<https://gcc.gnu.org/ml/gcc/2005-05/msg00377.html>.

I think this should become a target hook, where the default is 
implicit_extern_c returning false and only AIX (and any other OSes 
requiring it) sets the hook to return true.

> It also has the following undocumented features (when not set):

Whether these are needed would depend on the properties of headers for 
OSes setting the hook to return true.  Even if needed, one might consider 
fixing such header issues with fixincludes as a replacement for those 
features in the compiler.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Deprecate not defining NO_IMPLICIT_EXTERN_C

[Nathan Sidwell]

On 03/21/2018 05:28 PM, Joseph Myers wrote:

 > My list from 2005 of targets not defining NO_IMPLICIT_EXTERN_C then is
 > <https://gcc.gnu.org/ml/gcc/2005-05/msg00377.html>.

Thanks for the link.  I see you floated inverting the sense of the 
switch -- which would be good, as it appears we still can't remove it.

 > I think this should become a target hook, where the default is
 > implicit_extern_c returning false and only AIX (and any other OSes
 > requiring it) sets the hook to return true.

Yeah, I guess target hook might be the way to go these days.

Anyway, clearly a post-gcc8 thing.

nathan

-- 
Nathan Sidwell