strict_prototypes_lang_c

strict_prototypes_lang_c

[Mark Mitchell]

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

Re: strict_prototypes_lang_c

[Martin von Loewis]

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

I totally agree on the -ansi/-pedantic issue; it should be -ansi that
activates -fstrict-prototypes, not -pedantic.

I mostly agree on the default value: In C++, () always means (void),
and should not mean (...). I have no idea how many C++ programs still
link with K&R headers; so I'm not sure whether we really should change
the default.

Regards,
Martin

Re: strict_prototypes_lang_c

[Jeffrey A Law]

  In message < 199812140113.RAA07556@adsl-206-170-148-33.dsl.pacbell.net >you wri
te:
  > 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:
Agreed.


  > 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.
Does C++ have trigraphs?  Those are disabled, unless the -trigraphs option
is used.  As long as those are disabled by default, then we do not have
a strict superset of ANSI/ISO.


jeff

Re: strict_prototypes_lang_c

[Mark Mitchell]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

    Jeffrey> Does C++ have trigraphs?  Those are disabled, unless the

Yes.

    Jeffrey> -trigraphs option is used.  As long as those are disabled
    Jeffrey> by default, then we do not have a strict superset of
    Jeffrey> ANSI/ISO.

And that, in my opinion, is a bug.

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

Re: strict_prototypes_lang_c

[Jeffrey A Law]

  In message < 199812150802.AAA09238@adsl-206-170-148-33.dsl.pacbell.net >you
  > write:
  >     Jeffrey> -trigraphs option is used.  As long as those are disabled
  >     Jeffrey> by default, then we do not have a strict superset of
  >     Jeffrey> ANSI/ISO.
  > 
  > And that, in my opinion, is a bug.
Personally, I agree.

As long as RMS controlled the compiler, there was no hope of changing the
treatment of trigraphs.

That limitation is gone and I'm willing to consider turning on trigraphs by 
default if the general opinion of the egcs community is favorable.

jeff

Re: strict_prototypes_lang_c

[Horst von Brand]

Mark Mitchell <mark@markmitchell.com> said:
> >>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

>     Jeffrey> Does C++ have trigraphs?  Those are disabled, unless the

> Yes.

>     Jeffrey> -trigraphs option is used.  As long as those are disabled
>     Jeffrey> by default, then we do not have a strict superset of
>     Jeffrey> ANSI/ISO.

> And that, in my opinion, is a bug.

Seconded.
-- 
Dr. Horst H. von Brand                       mailto:vonbrand@inf.utfsm.cl
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: strict_prototypes_lang_c

[Gavin Romig-Koch]

Jeffrey A Law writes:
 > 
 >   In message < 199812150802.AAA09238@adsl-206-170-148-33.dsl.pacbell.net >you
 >   > write:
 >   >     Jeffrey> -trigraphs option is used.  As long as those are disabled
 >   >     Jeffrey> by default, then we do not have a strict superset of
 >   >     Jeffrey> ANSI/ISO.
 >   > 
 >   > And that, in my opinion, is a bug.
 > Personally, I agree.

From this thread it sounded like the primary reason for turning
on -trigraphs is to make "what's on by default" be a superset of
ANSI/ISO because that would make the options simpler.  If I 
understood this correctly, I think it's a mistake.

I think it's a mistake to decide to define "what's on by default
in gcc" as a superset of ANSI/ISO features.  In the long run
gcc needs the flexibility to decide that certain ANSI/ISO features
should not be on by default.  We need options that allow this,
and make this clear to our users.

I'm not opposed to turning on -trigraphs by default.  Like Jeff
said, if the consensus is to have them on, then by all means.  But
in the mean time, lets use trigraphs as an example to help us
improve and/or clarify our option flags.

                                           -gavin...





                                          -gavin...

Re: strict_prototypes_lang_c

[Mark Mitchell]

>>>>> "Gavin" == Gavin Romig-Koch <gavin@cygnus.com> writes:

    Gavin> I think it's a mistake to decide to define "what's on by
    Gavin> default in gcc" as a superset of ANSI/ISO features.  In the

But I don't.  So, perhaps you'd better explain what you mean a bit
more fully.  

But, perhaps the problem is that implicit in my statements was "for
C++".  In C, there is a much wider installed base of users, and there
are backward-compatibility concerns.

In C++, all the users I've talked to would like ANSI/ISO C++.  They
might also like some extensions, but I don't think they want any
ANSI/ISO C++ programs to not work.

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

Re: strict_prototypes_lang_c

[Joe Buck]

Jeff wrote:

> As long as RMS controlled the compiler, there was no hope of changing the
> treatment of trigraphs.

Note that the -ansi flag enables trigraphs; it doesn't seem too confusing
to tell users to use -ansi to get more standard behavior (though -ansi
seems a bit chauvinistic when -iso would be more meaningful to the
international community).

> That limitation is gone and I'm willing to consider turning on trigraphs by 
> default if the general opinion of the egcs community is favorable.

Question: are there users out there who have trouble entering any of the
standard C characters from their keyboards, because they have a 7-bit
keyboard with a national character set that does not have, say, the { or }
characters?  I have some sympathy for RMS's position: trigraphs are an
extremely ugly solution to a problem that no longer exists.

Another question: does enabling trigraphs do any potential harm to users
that are unaware of trigraphs?  I suppose you could accidentally include
a trigraph pattern in a string without knowing it, but it seems like a
low-probability event.

Re: strict_prototypes_lang_c

[Jeffrey A Law]

  In message < 199812151738.JAA12506@yamato.synopsys.com >you write:
  > Note that the -ansi flag enables trigraphs; it doesn't seem too confusing
  > to tell users to use -ansi to get more standard behavior (though -ansi
  > seems a bit chauvinistic when -iso would be more meaningful to the
  > international community).
Yea.  That does make the trigraph situation easier to swallow :-)

  > Question: are there users out there who have trouble entering any of the
  > standard C characters from their keyboards, because they have a 7-bit
  > keyboard with a national character set that does not have, say, the { or }
  > characters?  I have some sympathy for RMS's position: trigraphs are an
  > extremely ugly solution to a problem that no longer exists.
Dunno.


  > Another question: does enabling trigraphs do any potential harm to users
  > that are unaware of trigraphs?  I suppose you could accidentally include
  > a trigraph pattern in a string without knowing it, but it seems like a
  > low-probability event.
It can happen.  There is an option to warn about tri-graph sequences
-Wtrigraph.  However, it is only enabled when trigraphs are enabled.

jeff

Re: strict_prototypes_lang_c

[Jeffrey A Law]

  In message < 13942.31893.760353.315840@cetus.cygnus.com >you write:
  >  > Personally, I agree.
  > 
  > >From this thread it sounded like the primary reason for turning
  > on -trigraphs is to make "what's on by default" be a superset of
  > ANSI/ISO because that would make the options simpler.  If I 
  > understood this correctly, I think it's a mistake.
I can't speak for Mark, but for myself, it's merely a standards conformance
issue.  When in doubt I'll err on the side of following a standard instead of
doing something non-standard.

jeff

Re: strict_prototypes_lang_c

[Joe Buck]

>   In message < 13942.31893.760353.315840@cetus.cygnus.com >you write:
>   >  > Personally, I agree.
>   > 
>   > >From this thread it sounded like the primary reason for turning
>   > on -trigraphs is to make "what's on by default" be a superset of
>   > ANSI/ISO because that would make the options simpler.  If I 
>   > understood this correctly, I think it's a mistake.
> I can't speak for Mark, but for myself, it's merely a standards conformance
> issue.  When in doubt I'll err on the side of following a standard instead of
> doing something non-standard.

OK, how about making -trigraph -Wtrigraph the default.  That is, by
default recognize but warn about trigraphs.  I suspect even RMS would be
happy with that: we know what trigraphs are but "disapprove".  -ansi or
-pedantic could turn off -Wtrigraph.

Re: strict_prototypes_lang_c

[Martin von Loewis]

> I'm not opposed to turning on -trigraphs by default.  Like Jeff
> said, if the consensus is to have them on, then by all means.  But
> in the mean time, lets use trigraphs as an example to help us
> improve and/or clarify our option flags.

From the point of existing options, it seems clear that we either need
more options, or enable trigraphs by default. We have

-pedantic: If we accept it, and ISO doesn't, reject it

-ansi: If ISO accepts it, and we do, and there is a difference in
       semantics, favour ISO semantics

What we currently don't have is

-xyz: If we don't accept it by default, but ISO would, accept it.

Except for trigraphs, I can hardly imagine what feature we would
implement, but refuse to offer by default.

Of course, there is a number of cases were the ISO behaviour is
stupid, and we do something else instead by default (e.g. destructor
ordering). This is what -ansi is for, and this is what makes gcc not
to be a superset by default.

I can hardly see why strict subsetting in some area should be the
default.

Regards,
Martin

Re: strict_prototypes_lang_c

[Per Bothner]

> I can hardly see why strict subsetting in some area should be the
> default.

It is not strict subsetting - enable trigraphs silently changes
the meaning of existing programs.  For example:
	char xx[] = "??? what is going on here ??!";

So it seems -ansi is quite appropriate.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: strict_prototypes_lang_c

[Jeffrey A Law]

  In message < 199812151851.KAA26033@yamato.synopsys.com >you write:
  > 
  > >   In message < 13942.31893.760353.315840@cetus.cygnus.com >you write:
  > >   >  > Personally, I agree.
  > >   > 
  > >   > >From this thread it sounded like the primary reason for turning
  > >   > on -trigraphs is to make "what's on by default" be a superset of
  > >   > ANSI/ISO because that would make the options simpler.  If I 
  > >   > understood this correctly, I think it's a mistake.
  > > I can't speak for Mark, but for myself, it's merely a standards conforman
  > ce
  > > issue.  When in doubt I'll err on the side of following a standard instea
  > d of
  > > doing something non-standard.
  > 
  > OK, how about making -trigraph -Wtrigraph the default.  That is, by
  > default recognize but warn about trigraphs.  I suspect even RMS would be
  > happy with that: we know what trigraphs are but "disapprove".  -ansi or
  > -pedantic could turn off -Wtrigraph.
That would be fine by me too.

jeff

Re: strict_prototypes_lang_c

[Richard Earnshaw]

>   > Another question: does enabling trigraphs do any potential harm to users
>   > that are unaware of trigraphs?  I suppose you could accidentally include
>   > a trigraph pattern in a string without knowing it, but it seems like a
>   > low-probability event.
> It can happen.  There is an option to warn about tri-graph sequences
> -Wtrigraph.  However, it is only enabled when trigraphs are enabled.

cccp.c also turns it on if -Wall is passed.

        else if (!strcmp (argv[i], "-Wall"))
          {
            warn_trigraphs = 1;
            warn_comments = 1;
          }

Re: strict_prototypes_lang_c

[Joern Rennecke]

> 
> >   In message < 13942.31893.760353.315840@cetus.cygnus.com >you write:
> >   >  > Personally, I agree.
> >   > 
> >   > >From this thread it sounded like the primary reason for turning
> >   > on -trigraphs is to make "what's on by default" be a superset of
> >   > ANSI/ISO because that would make the options simpler.  If I 
> >   > understood this correctly, I think it's a mistake.
> > I can't speak for Mark, but for myself, it's merely a standards conformance
> > issue.  When in doubt I'll err on the side of following a standard instead of
> > doing something non-standard.
> 
> OK, how about making -trigraph -Wtrigraph the default.  That is, by
> default recognize but warn about trigraphs.  I suspect even RMS would be
> happy with that: we know what trigraphs are but "disapprove".  -ansi or
> -pedantic could turn off -Wtrigraph.

turning off warings with -ansi sounds weird to me.  Tunring it off with
-pedantic even more so.
The standard allows the compiler to emit as many warnings as it likes,
so this is not a conformance issue.
Moreover, even if all C compilers handled trigraphs, there is still the
issue that they can confuse programmers, and programming tools like
lint, yacc or grep.
So it makes sense to warn about trirgaphs unless you shut the warning off
with -Wno-trigraphs .