strict_prototypes_lang_c

[Mark Mitchell <mark at markmitchell dot com>]

This test-case appeared on the bug-list recently:

  extern "C" {
  void empty_parens(void (*callback)());
  }

  void
  empty_parens(void (*callback)())
  {
  }

Here, we don't think that these two functions are the same (and hence
mangle the definition, rather than leaving it unmangled as per extern
"C".)

The reason, of course, is that we treat the `()' as `(...)' in the
`extern "C"' scope, but not at namespace scope.  The reason for that
is that strict_prototypes_lang_c is set only if -fstrict-prototypes.
Thus, there are four ways to work-around this bug:

  o -fstrict-prototypes
  o -pedantic (which implies -fstrict-prototypes)
  o Use `(...)' at the defininition
  o Use `(void)' in the declaration.

This is bogus in several ways.  For one thing, -pedantic should
*never, ever* change the meaning of a program.  It should only 
cause illegal programs to be rejected:

  `-pedantic'
     Issue all the warnings demanded by strict ANSI C and ISO C++;
     reject all programs that use forbidden extensions.

Every now and then, we g++ implementors try to use -pedantic to change
the behavior of programs, but we should not.  It's just wrong, doesn't
match the documentation, and is plain confusing.  Please, let's make
-pedantic be a `warning option', as the documentation promises.  

I think that our default mode should be a *superset* of ANSI/ISO C++
programs, i.e., ANSI/ISO with some appropriate extensions.  Using
-pedantic should restrict this mode by removing the extensions.  Thus,
-fstrict-prototypes should be the default, as per standard C++.  You
should have to use -fno-strict-prototypes to make `extern "C"' things
treat `()' as `(...)', IMO.

If we really need to have the default mode be something other than a
superset of ANSI/ISO C++, then -ansi is the flag that should be used
to get ANSI/ISO C++ (and maybe some extensions), not -pedantic.

In this particular case, of course, we could fix the bug by making
sure that strict_prototype always applies to nested parameter lists
(i.e., parameter lists occuring within parameter lists).
Unfortunateyl, this is non-trivial using the current bison parser; if
only I had the resources to finish the partially-complete recursive
descent parser I started! :-(

However, although that would fix this ase, it would not fix the more
general situation: `extern "C" void f()' does not have the correct
ANSI/ISO type.

Thoughts?

-- 
Mark Mitchell 			mark@markmitchell.com
Mark Mitchell Consulting	http://www.markmitchell.com