* Deprecate not defining NO_IMPLICIT_EXTERN_C
@ 2018-03-21 12:32 Nathan Sidwell
2018-03-21 14:18 ` Richard Earnshaw (lists)
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Nathan Sidwell @ 2018-03-21 12:32 UTC (permalink / raw)
To: GCC Patches, Jason Merrill
Cc: Richard Earnshaw, rth, gnu, Nick Clifton, chertykov, jzhang918,
Bernd Schmidt, hp, james.bowman, Jeff Law, Jan Hubicka,
Jim Wilson, sebastien, eager, clm, green, jasonwucj, cltang, tom,
ni1d, kito.cheng, dj, David Edelsohn, hepenner, Alexandre Oliva,
davem, walt, matt, ebotcazou, augustine.sterling
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Deprecate not defining NO_IMPLICIT_EXTERN_C
2018-03-21 12:32 Deprecate not defining NO_IMPLICIT_EXTERN_C Nathan Sidwell
@ 2018-03-21 14:18 ` Richard Earnshaw (lists)
2018-03-21 14:38 ` David Edelsohn
2018-03-21 21:33 ` Joseph Myers
2 siblings, 0 replies; 6+ messages in thread
From: Richard Earnshaw (lists) @ 2018-03-21 14:18 UTC (permalink / raw)
To: Nathan Sidwell, GCC Patches, Jason Merrill
Cc: rth, gnu, nickc, chertykov, jzhang918, Bernd Schmidt, hp,
james.bowman, Jeff Law, Jan Hubicka, Jim Wilson, sebastien,
eager, clm, green, jasonwucj, cltang, tom, ni1d, kito.cheng, dj,
David Edelsohn, hepenner, Alexandre Oliva, davem, walt, matt,
ebotcazou, augustine.sterling
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Deprecate not defining NO_IMPLICIT_EXTERN_C
2018-03-21 12:32 Deprecate not defining NO_IMPLICIT_EXTERN_C Nathan Sidwell
2018-03-21 14:18 ` Richard Earnshaw (lists)
@ 2018-03-21 14:38 ` David Edelsohn
2018-03-21 15:42 ` Nathan Sidwell
2018-03-21 21:33 ` Joseph Myers
2 siblings, 1 reply; 6+ messages in thread
From: David Edelsohn @ 2018-03-21 14:38 UTC (permalink / raw)
To: Nathan Sidwell, GCC Patches
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Deprecate not defining NO_IMPLICIT_EXTERN_C
2018-03-21 14:38 ` David Edelsohn
@ 2018-03-21 15:42 ` Nathan Sidwell
0 siblings, 0 replies; 6+ messages in thread
From: Nathan Sidwell @ 2018-03-21 15:42 UTC (permalink / raw)
To: David Edelsohn, GCC Patches
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Deprecate not defining NO_IMPLICIT_EXTERN_C
2018-03-21 12:32 Deprecate not defining NO_IMPLICIT_EXTERN_C Nathan Sidwell
2018-03-21 14:18 ` Richard Earnshaw (lists)
2018-03-21 14:38 ` David Edelsohn
@ 2018-03-21 21:33 ` Joseph Myers
2018-03-22 12:16 ` Nathan Sidwell
2 siblings, 1 reply; 6+ messages in thread
From: Joseph Myers @ 2018-03-21 21:33 UTC (permalink / raw)
To: Nathan Sidwell
Cc: GCC Patches, Jason Merrill, Richard Earnshaw, rth, gnu,
Nick Clifton, chertykov, jzhang918, Bernd Schmidt, hp,
james.bowman, Jeff Law, Jan Hubicka, Jim Wilson, sebastien,
eager, clm, green, jasonwucj, cltang, tom, ni1d, kito.cheng, dj,
David Edelsohn, hepenner, Alexandre Oliva, davem, walt, matt,
ebotcazou, augustine.sterling
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Deprecate not defining NO_IMPLICIT_EXTERN_C
2018-03-21 21:33 ` Joseph Myers
@ 2018-03-22 12:16 ` Nathan Sidwell
0 siblings, 0 replies; 6+ messages in thread
From: Nathan Sidwell @ 2018-03-22 12:16 UTC (permalink / raw)
To: Joseph Myers; +Cc: GCC Patches
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-03-22 12:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-21 12:32 Deprecate not defining NO_IMPLICIT_EXTERN_C Nathan Sidwell
2018-03-21 14:18 ` Richard Earnshaw (lists)
2018-03-21 14:38 ` David Edelsohn
2018-03-21 15:42 ` Nathan Sidwell
2018-03-21 21:33 ` Joseph Myers
2018-03-22 12:16 ` Nathan Sidwell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).