Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Jason Merrill:

> As a compromise, it should be possible to error by default only in
> cases where the implicit int (including as a return value) is either
> the source or target of a non-value-preserving conversion, as those
> are very likely to be bugs.  That seems desirable for both camps.

Not sure, malloc returning 31-bit pointers goes a long way towards
maintaining int/pointer compatibility for 64-bit systems, too.  People
might actually have a working implicit-declared malloc on 64-bit today,
and still argue against the changes.

> A simpler change to catch this particular bug would be to make
> -Wint-conversion an error by default iff the sizes differ.

That doesn't address other bugs around implicitly-declared functions,
such as the bool/int ABI incompatibility, or the lack of type checking
for arguments.  I don't see those programmer mistakes because I think
it's easier to debug them on your own: swapped arguments are visible in
the source code, and GDB probably gives you enough data as well.  So I
suspect that people figure this out on their own.  They are still
wasting time on this, but probably somewhat less.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Jason Merrill via Gcc]

On Tue, May 16, 2023 at 3:06 AM Florian Weimer via Gcc 
wrote:

> * Eric Gallager via Gcc:
>
> > I support this plan for using -Werror= and having it be split based on
> > whether -std= is set to a strict ANSI option or a GNU option; is there
> > a way to do that in the optfiles, or would it have to be handled at
> > the specs level instead?
>
> This isn't going to work well because -std=c17 (for example) disables
> _DEFAULT_SOURCE for glibc, so lots of declarations go missing from the
> glibc header files.  I don't see why these things should be tied
> together because as I see it, this is not about standards conformance
> (warnings make GCC conforming already), but programmer convenience.
>

Agreed, -std=c?? is supposed to disable only the extensions that conflict
with accepting all conforming code.  Diagnosing non-conforming code is the
job of -pedantic(-errors).

Can you explain again why upgrading -Wint-conversion (instead of
-Wimplicit) isn't the right solution for catching these bugs?  You
mentioned that this would need more changes to Fedora packages, but
wouldn't those cases also be fixing real bugs, unlike the changes needed to
avoid -Wimplicit in autoconf?

Jason

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Jakub Jelinek:

> On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
>> 
>> On Tue, 16 May 2023, Florian Weimer wrote:
>> 
>> > > (FWIW: no, this should not be an error, a warning is fine, and I 
>> > > actually 
>> > > think the current state of it not being in Wall is the right thing as 
>> > > well)
>> 
>> (this is mixed up, -Wpointer-sign is in fact enabled by -Wall)
>> 
>> > I don't understand why we do not warn by default and warn with -Wall.  I
>> > would expect this to be either a documented extension (no warning with
>> > -Wall), or a warning by default (because it's a conformance issue).  Is
>> > there any conformance issue that is treated in the same way?
>> 
>> Another one is -Wpointer-arith (pointer arithmetic on 'void *').
>
> That is a documented GNU extension, so we shouldn't increase severity of
> the diagnostics from the current state.

Right, it's also widely used, and harmless for void *.  For function
pointers, it's much more dubious, and not meaningful at all for some
targets.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Tue, 16 May 2023 at 12:01, Jakub Jelinek wrote:
>
> On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
> >
> > On Tue, 16 May 2023, Florian Weimer wrote:
> >
> > > > (FWIW: no, this should not be an error, a warning is fine, and I 
> > > > actually
> > > > think the current state of it not being in Wall is the right thing as
> > > > well)
> >
> > (this is mixed up, -Wpointer-sign is in fact enabled by -Wall)
> >
> > > I don't understand why we do not warn by default and warn with -Wall.  I
> > > would expect this to be either a documented extension (no warning with
> > > -Wall), or a warning by default (because it's a conformance issue).  Is
> > > there any conformance issue that is treated in the same way?
> >
> > Another one is -Wpointer-arith (pointer arithmetic on 'void *').
>
> That is a documented GNU extension, so we shouldn't increase severity of
> the diagnostics from the current state.

I was about to say that this one really is a documented extension.
It's caused a few bugs in libstdc++ over the years though. Arithmetic
on void* makes sense, but pointer arithmetic on function pointers is
just weird.

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Tue, May 16, 2023 at 01:39:26PM +0300, Alexander Monakov wrote:
> 
> On Tue, 16 May 2023, Florian Weimer wrote:
> 
> > > (FWIW: no, this should not be an error, a warning is fine, and I actually 
> > > think the current state of it not being in Wall is the right thing as 
> > > well)
> 
> (this is mixed up, -Wpointer-sign is in fact enabled by -Wall)
> 
> > I don't understand why we do not warn by default and warn with -Wall.  I
> > would expect this to be either a documented extension (no warning with
> > -Wall), or a warning by default (because it's a conformance issue).  Is
> > there any conformance issue that is treated in the same way?
> 
> Another one is -Wpointer-arith (pointer arithmetic on 'void *').

That is a documented GNU extension, so we shouldn't increase severity of
the diagnostics from the current state.

Jakub

Re: More C type errors by default for GCC 14

[Alexander Monakov via Gcc]

On Tue, 16 May 2023, Florian Weimer wrote:

> > (FWIW: no, this should not be an error, a warning is fine, and I actually 
> > think the current state of it not being in Wall is the right thing as 
> > well)

(this is mixed up, -Wpointer-sign is in fact enabled by -Wall)

> I don't understand why we do not warn by default and warn with -Wall.  I
> would expect this to be either a documented extension (no warning with
> -Wall), or a warning by default (because it's a conformance issue).  Is
> there any conformance issue that is treated in the same way?

Another one is -Wpointer-arith (pointer arithmetic on 'void *').

Alexander

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Michael Matz:

> Hello,
>
> On Fri, 12 May 2023, Florian Weimer wrote:
>
>> * Alexander Monakov:
>> 
>> > This is not valid (constraint violation):
>> >
>> >   unsigned x;
>> >
>> >   int *p = 
>> >
>> > In GCC this is diagnosed under -Wpointer-sign:
>> >
>> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
>> 
>> Thanks for the reference.  I filed:
>> 
>>   -Wpointer-sign must be enabled by default
>>   
>
> Can you please not extend the scope of your proposals in this thread but 
> create a new one?

I understood Joseph as asking for exploring a broadened scope, so I
looked into that.

> (FWIW: no, this should not be an error, a warning is fine, and I actually 
> think the current state of it not being in Wall is the right thing as 
> well)

I don't understand why we do not warn by default and warn with -Wall.  I
would expect this to be either a documented extension (no warning with
-Wall), or a warning by default (because it's a conformance issue).  Is
there any conformance issue that is treated in the same way?

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Florian Weimer via Gcc]

* Eric Gallager via Gcc:

> I support this plan for using -Werror= and having it be split based on
> whether -std= is set to a strict ANSI option or a GNU option; is there
> a way to do that in the optfiles, or would it have to be handled at
> the specs level instead?

This isn't going to work well because -std=c17 (for example) disables
_DEFAULT_SOURCE for glibc, so lots of declarations go missing from the
glibc header files.  I don't see why these things should be tied
together because as I see it, this is not about standards conformance
(warnings make GCC conforming already), but programmer convenience.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Eric Gallager via Gcc]

On 5/15/23, Richard Earnshaw (lists) via Gcc  wrote:
> On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:
>>> From: Arsen Arsenović 
>>> Cc: Eli Zaretskii , Jakub Jelinek ,
>>>   jwakely@gmail.com, gcc@gcc.gnu.org
>>> Date: Tue, 09 May 2023 22:21:03 +0200
>>>
 The concern is using the good will of the GNU Toolchain brand as the tip
 of
 the spear or battering ram to motivate software packages to fix their
 problems. It's using GCC as leverage in a manner that is difficult for
 package maintainers to avoid.  Maybe that's a necessary approach, but
 we
 should be clear about the reasoning.  Again, I'm not objecting, but
 let's
 clarify why we are choosing this approach.
>>>
>>> Both the GNU Toolchain and the GNU Toolchain users will benefit from a
>>> stricter toolchain.
>>>
>>> People can and have stopped using the GNU Toolchain due to lackluster
>>> and non-strict defaults.  This is certainly not positive for the brand,
>>> and I doubt it buys it much good will.
>>
>> It is not GCC's business to force developers of packages to get their
>> act together.  It is the business of those package developers
>> themselves.  GCC should give those developers effective and convenient
>> means of detecting any unsafe and dubious code and of correcting it as
>> they see fit.  Which GCC already does by emitting warnings.  GCC
>> should only error out if it is completely unable to produce valid
>> code, which is not the case here, since it has been producing valid
>> code for ages.
>>
>> It is a disservice to GCC users if a program that compiled yesterday
>> and worked perfectly well suddenly cannot be built because GCC was
>> upgraded, perhaps due to completely unrelated reasons.  It would be a
>> grave mistake on the part of GCC to decide that part of its mission is
>> to teach package developers how to write their code and when and how
>> to modify it.
>
> That argument doesn't really wash.  We already upgrade the 'default'
> language version (-std=...) from time to time and that can impact
> existing programs (eg we changed from gnu-inline to std-inline model).
>
> If this really isn't legal C, then my suggestion would be to tie this to
> a setting of -std, so -std=c2 would default to being more
> aggressive in enforcing this (via changing the warning to -werror=) and
> then -std=gnu2 might follow a bit behind that.
> Furthermore, we can trail this aggressively in release notes so that
> nobody can really claim to be surprised.
>

I support this plan for using -Werror= and having it be split based on
whether -std= is set to a strict ANSI option or a GNU option; is there
a way to do that in the optfiles, or would it have to be handled at
the specs level instead?

> At some point that std setting will become the default and the overall
> goal is achieved.
>
> R.
>

Re: More C type errors by default for GCC 14

[Richard Earnshaw (lists) via Gcc]

On 12/05/2023 13:30, Jakub Jelinek via Gcc wrote:

On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:

One fairly big GCC-internal task is to clear up the C test suite so that
it passes with the new compiler defaults.  I already have an offer of
help for that, so I think we can complete this work in a reasonable time
frame.


I'd prefer to keep at least significant portion of those tests as is with
-fpermissive added (plus of course we need new tests that verify the errors
are emitted), so that we have some testsuite coverage for those.


Whilst there is historical precedent for -fpermissive, I have to say 
that I don't like it.  The problem is that it is too imprecise as to 
what it means (and changes over time).  It also becomes the lazy way to 
paper over the problems being exposed and, in future, may mean that 
other (perhaps more important) issues that are detectable will be 
silently ignored if it becomes widely used.


R.

Re: More C type errors by default for GCC 14

[Michael Matz via Gcc]

Hello,

On Fri, 12 May 2023, Florian Weimer wrote:

> * Alexander Monakov:
> 
> > This is not valid (constraint violation):
> >
> >   unsigned x;
> >
> >   int *p = 
> >
> > In GCC this is diagnosed under -Wpointer-sign:
> >
> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892
> 
> Thanks for the reference.  I filed:
> 
>   -Wpointer-sign must be enabled by default
>   

Can you please not extend the scope of your proposals in this thread but 
create a new one?

(FWIW: no, this should not be an error, a warning is fine, and I actually 
think the current state of it not being in Wall is the right thing as 
well)


Ciao,
Michael.

Re: More C type errors by default for GCC 14

[Michael Matz via Gcc]

Hello,

On Fri, 12 May 2023, Jakub Jelinek via Gcc wrote:

> On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
> > > One fairly big GCC-internal task is to clear up the C test suite so that
> > > it passes with the new compiler defaults.  I already have an offer of
> > > help for that, so I think we can complete this work in a reasonable time
> > > frame.
> 
> I'd prefer to keep at least significant portion of those tests as is with
> -fpermissive added (plus of course we need new tests that verify the errors
> are emitted), so that we have some testsuite coverage for those.

Yes, this!  Try to (!) never change committed testcase souces, however 
invalid they may be (changing how they are compiled, including by 
introducing new dg-directives and using them in comments, is of course 
okay).

(And FWIW: I'm fine with Florians proposal.  I personally think the 
arguments for upgrading the warnings to errors are _not_ strong enough, 
but I don't think so very strongly :) )


Ciao,
Michael.

Re: More C type errors by default for GCC 14

[Richard Earnshaw (lists) via Gcc]

On 10/05/2023 03:38, Eli Zaretskii via Gcc wrote:

From: Arsen Arsenović 
Cc: Eli Zaretskii , Jakub Jelinek ,
  jwakely@gmail.com, gcc@gcc.gnu.org
Date: Tue, 09 May 2023 22:21:03 +0200


The concern is using the good will of the GNU Toolchain brand as the tip of
the spear or battering ram to motivate software packages to fix their
problems. It's using GCC as leverage in a manner that is difficult for
package maintainers to avoid.  Maybe that's a necessary approach, but we
should be clear about the reasoning.  Again, I'm not objecting, but let's
clarify why we are choosing this approach.


Both the GNU Toolchain and the GNU Toolchain users will benefit from a
stricter toolchain.

People can and have stopped using the GNU Toolchain due to lackluster
and non-strict defaults.  This is certainly not positive for the brand,
and I doubt it buys it much good will.


It is not GCC's business to force developers of packages to get their
act together.  It is the business of those package developers
themselves.  GCC should give those developers effective and convenient
means of detecting any unsafe and dubious code and of correcting it as
they see fit.  Which GCC already does by emitting warnings.  GCC
should only error out if it is completely unable to produce valid
code, which is not the case here, since it has been producing valid
code for ages.

It is a disservice to GCC users if a program that compiled yesterday
and worked perfectly well suddenly cannot be built because GCC was
upgraded, perhaps due to completely unrelated reasons.  It would be a
grave mistake on the part of GCC to decide that part of its mission is
to teach package developers how to write their code and when and how
to modify it.


That argument doesn't really wash.  We already upgrade the 'default' 
language version (-std=...) from time to time and that can impact 
existing programs (eg we changed from gnu-inline to std-inline model).


If this really isn't legal C, then my suggestion would be to tie this to 
a setting of -std, so -std=c2 would default to being more 
aggressive in enforcing this (via changing the warning to -werror=) and 
then -std=gnu2 might follow a bit behind that. 
Furthermore, we can trail this aggressively in release notes so that 
nobody can really claim to be surprised.


At some point that std setting will become the default and the overall 
goal is achieved.


R.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Arsen Arsenović  writes:

> Any development style making documentation a source of truth matches
> this principle.  This does not refer to ISO specifications specifically,
> though, normally, unless the standard disagrees with reality, as
> implicit-... did many years ago, ISO decisions are taken seriously.

We're not talking about the C Standard here.  Eli S. is claiming that
gcc.info is the source of truth for the behavior of GCC, and whenever
some behavior of GCC is not documented (or contradicts the
documentation), GCC should be fixed to behave as its documentation
specifies.

> It is, after this proposal is accepted, still up to the user to decide.
> The only difference is that the default would be friendlier to new code
> and users and most code that exists today, rather than to very old code
> and incorrect code.

That's not correct.  It would be as friendly to new code as it is now --
but old (and very likely still correct) code would be put at a
disadvantage.

> Additionally, there isn't enough information to compile.  The compiler
> makes up new information to fill in the gaps.

According to a specific formula that all C programmers (at least, those
who write such code) know.

> If that definition accepted, most error recovery should be turned into
> valid code paths that participate as GNU extensions, for instance,
> there's no reason that:
>
>int f (int x) { x += 10 return x + 123 }
>
> shouldn't compile, as the compiler knows where to insert semicolons to
> make it (probably) work.  I'd say that extension is more acceptable than
> the ones being proposed into turning into errors by default, since it
> isn't very ambiguous, unlike an implicit function declaration or such.

Unfortunately, this has never worked in any C compiler, and is very
ambiguous.  Implicit int and function declarations have been included in
every ANSI and K C compiler, and then some more after that, so what
the compiler should do is very precisely specified and known.

> It has been 25 years since the addition of -fpermissive to G++.  I'm
> optimistic.

But -fpermissive is considered ``useful'' by the many loud people who
find it necessary to compile C as C++.

Re: More C type errors by default for GCC 14

[Nicholas Vinson via Gcc]

Jonathan Wakely  writes:

Wrong. I wouldn't bother replying to you again in this thread, but I
feel that as a gcc maintainer I should confirm that Eli S. is right
here; and nobody else I know agrees with your definition of extension
as "every non-standard aspect of the compiler's behaviour, whether
intentional or accidental". That's just silly.

GCC's support for implicit int is clearly intentional.
I never claimed that accidental GNU CC behavior was part of GNU C.


You might not have explicitly stated that, but you have made that 
argument in this thread.


You have asserted that the compiler's behavior, and not its 
documentation, determines what should be consider a language extension.


That assertion when taken to its natural conclusion show support for the 
idea that "accidental GNU CC behavior" should be considered a language 
extension, and by becoming a language extension it would be part of GNU C.


If the behavior, and not the documentation, determines what is and is 
not an extension unless it's "accidental behavior", then how is anyone 
to know what is or is not a GNU C extension?

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Po Lu via Gcc  writes:

...

> Where is it written that GNU CC follows your so-called
> ``specification-driven development''?

Any development style making documentation a source of truth matches
this principle.  This does not refer to ISO specifications specifically,
though, normally, unless the standard disagrees with reality, as
implicit-... did many years ago, ISO decisions are taken seriously.

> Here is an explanation from one of the original GCC developers.  It
> discusses strict aliasing, but the same principles apply here:
>
> (199909100634.caa01...@psilocin.gnu.org)
>
>   My comment is similar to Mark's comment.  Documentation, what can
>   we document as working?
>
>   We should not even try to document that these cases work.
>   Documentation is what we do when we add a feature.
>
>   I am not proposing this as a feature, just as a way to avoid evitable
>   trouble for users.  We should not even try to document a class of
>   cases that are "supposed" to work, because I'm not saying these are
>   "supposed" to work.  We should just let them work.
>
>
>   Anway, more questions from me than answers...  Off hand though, if
>   we can make the compiler generate `right' code in more cases, even
>   if the users code is wrong, I think we should probably do it.
>
>   In C, we cannot divide all user code into "right" and "wrong" in this
>   kind of simple way, and certainly not based on the ISO standard.  That
>   standard is just the decisions of a certain committee (which I was a
>   member of) about what cases conforming compilers should commit to
>   support.  We must not let ourselves start thinking that C code is
>   "wrong", just because it is not conforming ISO C code.
>
>   C programs use many cases that are not conforming, but do work.  This
>   will be true for as long as C is used, because changing it would
>   require major changes in the C language.
>
>   From time to time, there is a real *need* to make some of these cases
>   stop working, for the sake of some benefit that users want.  When this
>   happens, we should do it; the user community will accept it, because
>   they will see that it is being done for their sake.  Some will
>   grumble, but the users who appreciate the benefits will convince them.
>
>   But when there is no *need* to break these cases, when we can keep
>   them working fairly easily, we should keep them working.  If we break
>   them unnecessarily, we invite the legitimate anger of the users.
>
> and another (199909100634.caa01...@psilocin.gnu.org):
>
>   However, I have a rather serious objection: it means that users
>   cannot tell whether their code is valid, even according to the GCC
>   rules, without knowing the internals of the compiler.
>
>   This has always been true.  It is true in the current version of GCC
>   with regard to aliasing, even when -fstrict-aliasing is used.  It is
>   part of the nature of C.
>
>   The goal of trying to avoid it is unrealistic and misguided; it can't
>   be done.  So this cannot be a valid reason to reject a change.
>
>   The compiler should continue to aggressively break code that
>   misbehaves in this way.
>
>   This proposes to break users' code, just to bully them into changing
>   it.  That is a callous and harsh attitude towards the users of GCC.
>   No wonder users are angry.  They know that the problems are not due to
>   necessity, but due to callous disregard for them.
>
>   We cannot do everything all users want, and sometimes a maintainer has
>   to say no to users.  "You cannot please everyone," as the saying goes.
>   There are many kinds of reasons which can sometimes be good reasons to
>   say no.
>
>   But maintainers should always say no reluctantly--never eagerly.  We
>   should never aggressively cause trouble for users today, just because
>   someday it might be necessary.  That is like amputating limbs because
>   someday they might be crushed.
>
>   This treatment of users brings shame on the GNU Project.  I ask
>   everyone therefore not to suggest that we should treat users this way.
>
>> Sound familiar? A bit like GCC triggering a warning, telling you that
>> what you're doing is bad and should not be relied on?
>
> A diagnostic message is supposed to inform me of a diagnosis by the
> translator.  The severity of the diagnosis, is, as always, up to the
> user to decide, as long as enough information remains for translation to
> continue.

It is, after this proposal is accepted, still up to the user to decide.
The only difference is that the default would be friendlier to new code
and users and most code that exists today, rather than to very old code
and incorrect code.

Additionally, there isn't enough information to compile.  The compiler
makes up new information to fill in the gaps.

If that definition accepted, most error recovery should be turned into
valid code paths that participate as GNU 

Re: More C type errors by default for GCC 14

[Mark Wielaard]

Hi Po,

On Fri, May 12, 2023 at 09:53:30PM +0800, Po Lu via Gcc wrote:
> I don't want anything, seeing as I've been using GCC less and less over
> the years (for this and other reasons.)  I'm just throwing in my two or
> so cents.

I think you have contributed more than two cents and it time to stop
repeating your opinion over and over again (and for others to stop
replying to your posts). You have posted more than anybody else to
this thread and it is not contributing anything new. Please let the
actual gcc maintainers work out the technical details of the default
diagnostics.

Thanks,

Mark

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Jonathan Wakely  writes:

> Wrong. I wouldn't bother replying to you again in this thread, but I
> feel that as a gcc maintainer I should confirm that Eli S. is right
> here; and nobody else I know agrees with your definition of extension
> as "every non-standard aspect of the compiler's behaviour, whether
> intentional or accidental". That's just silly.

GCC's support for implicit int is clearly intentional.
I never claimed that accidental GNU CC behavior was part of GNU C.

> No, Eli S. is quite right.

[...]

> And when the compiler is wrong and the documentation is correct, the
> compiler is fixed.

And the documentation is wrong, while the translator is correct.

GCC development, being part of the GNU project, is supposed to act in
its interests and that of Free Software in general.  I remind you of of
this statement, which was made here, on this list, by clearer minds:

  We cannot do everything all users want, and sometimes a maintainer has
  to say no to users.  "You cannot please everyone," as the saying goes.
  There are many kinds of reasons which can sometimes be good reasons to
  say no.

  But maintainers should always say no reluctantly--never eagerly.  We
  should never aggressively cause trouble for users today, just because
  someday it might be necessary.  That is like amputating limbs because
  someday they might be crushed.

  This treatment of users brings shame on the GNU Project.  I ask
  everyone therefore not to suggest that we should treat users this way.

And yes, such shameful treatment is directly harmful to the goals of the
GNU Project: at least one organization, likely more, has been forced to
adopt proprietary compilers as a direct result.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> Does this mean you've conceded the point, and no longer think it is
> written in C++?

No.

> You are correct in reading my sentence, that is indeed what I said.
>
> Aside: you have reiterated "the behavior of the translator itself" over
> and over again, but it hasn't been generally reiterated, or even iterated.

Parse error.

> Repeating this statement won't make it true.

Before you say this, I suggest that you take some time to look at
yourself in a mirror.

> In fact, lots and lots and lots of programs do indeed operate such that
> the documentation specifies how the program shall behave, and when the
> program fails to behave in the manner in which it is documented to
> behave, the program shall be fixed.
>
> We call these failures to behave according to the documentation,
>
>
> Bugs.
>
>
> Occasionally it is also called specification-driven development.
>
> ...
>
> In cases where the documentation says nothing at all, for good or ill,
> the behavior of the program is undefined -- users cannot rely on it, for
> they cannot know what is intended and what is not intended -- in this
> case, the intended behavior must be defined, documented, and
> implemented, and "the program currently does X" gets one vote out of
> many and is not guaranteed to get its way.
>
> Very often in such cases the best user-serving thing to do is to define
> the behavior as "shall not be used, and for legacy reasons if you use it
> it will continue to do X but raise a warning telling you that you are
> required to stop depending on it" and possibly even "it may disappear in
> semver version YYY".

Where is it written that GNU CC follows your so-called
``specification-driven development''?

Here is an explanation from one of the original GCC developers.  It
discusses strict aliasing, but the same principles apply here:

(199909100634.caa01...@psilocin.gnu.org)

  My comment is similar to Mark's comment.  Documentation, what can
  we document as working?

  We should not even try to document that these cases work.
  Documentation is what we do when we add a feature.

  I am not proposing this as a feature, just as a way to avoid evitable
  trouble for users.  We should not even try to document a class of
  cases that are "supposed" to work, because I'm not saying these are
  "supposed" to work.  We should just let them work.
   

  Anway, more questions from me than answers...  Off hand though, if
  we can make the compiler generate `right' code in more cases, even
  if the users code is wrong, I think we should probably do it.

  In C, we cannot divide all user code into "right" and "wrong" in this
  kind of simple way, and certainly not based on the ISO standard.  That
  standard is just the decisions of a certain committee (which I was a
  member of) about what cases conforming compilers should commit to
  support.  We must not let ourselves start thinking that C code is
  "wrong", just because it is not conforming ISO C code.

  C programs use many cases that are not conforming, but do work.  This
  will be true for as long as C is used, because changing it would
  require major changes in the C language.

  From time to time, there is a real *need* to make some of these cases
  stop working, for the sake of some benefit that users want.  When this
  happens, we should do it; the user community will accept it, because
  they will see that it is being done for their sake.  Some will
  grumble, but the users who appreciate the benefits will convince them.

  But when there is no *need* to break these cases, when we can keep
  them working fairly easily, we should keep them working.  If we break
  them unnecessarily, we invite the legitimate anger of the users.

and another (199909100634.caa01...@psilocin.gnu.org):

  However, I have a rather serious objection: it means that users
  cannot tell whether their code is valid, even according to the GCC
  rules, without knowing the internals of the compiler.

  This has always been true.  It is true in the current version of GCC
  with regard to aliasing, even when -fstrict-aliasing is used.  It is
  part of the nature of C.

  The goal of trying to avoid it is unrealistic and misguided; it can't
  be done.  So this cannot be a valid reason to reject a change.

  The compiler should continue to aggressively break code that
  misbehaves in this way.

  This proposes to break users' code, just to bully them into changing
  it.  That is a callous and harsh attitude towards the users of GCC.
  No wonder users are angry.  They know that the problems are not due to
  necessity, but due to callous disregard for them.

  We cannot do everything all users want, and sometimes a maintainer has
  to say no to users.  "You cannot please everyone," as the saying goes.
  There are many kinds of reasons which can sometimes be good reasons to
  say no.

  But maintainers should always 

Re: More C type errors by default for GCC 14

[David Brown]

On 14/05/2023 07:28, Po Lu via Gcc wrote:

Eli Schwartz  writes:


Quoting my previous reply on the topic.

Until everyone is on the same page as you about whether these are GNUC
extensions, this conversation will go nowhere.

You are of the opinion that "GCC currently behaves a certain way when
compiling the code" means that the behavior is documented and specified
as a "C Extension" for the GNUC language dialect.


Yes, by the definition of ``extension'' used by everyone except you.


I can't speak for "everyone", and I don't think you can either.  But I 
believe I am safe in saying that everyone who has expressed an opinion 
in this thread, agrees with Eli's definition - GCC C extensions are what 
the GCC C manual documents as extensions.


The behaviour of a particular compiler does not define the extensions. 
At best, these are "undocumented features" - if you find them consistent 
enough and useful enough on a particular version of a particular 
compiler, then you may be willing to rely on them despite a lack of any 
kind of guarantees or documentation.


(You might note that there are several compilers, not just GCC, that 
implement many of the GNU C extensions.  I don't believe any of them 
makes any guarantees about your imagined undocumented extensions either.)





Undefined and undocumented behavior is not a language extension. It is
undefined and undocumented behavior.


But when it becomes defined by the translator, in a precise way, it
becomes an extension to the Standard.


No, it becomes an artefact of the particular implementation.  And if you 
have studied that implementation closely enough to see that it fulfils 
the specifications you want, not just its actual specifications, then 
feel free to keep that implementation and use it.  But you have 
absolutely no basis for expecting that any other implementation (such as 
future gcc versions) implement the same undocumented specifications.





You may feel free to take an exact GCC release (source or binary),
analyze it, reverse-engineer it, or verify that it does what you want
it to do, and then trust that those undefined and undocumented
behaviors are ***benevolent***, but that doesn't cause it to be
defined and documented, and your trust will, if you are wise, depend
on you pinning an exact source code commit of the compiler. Do not
depend on bugfix releases of GCC to preserve your undocumented
semantics. They may or they may not, but if they don't, it's not a GCC
bug, because it is ***undocumented***.


GCC does not implement its documentation.  The documentation is supposed
to describe (_not_ specify) how GCC behaves, and when the documentation
is wrong or contains omissions, the documentation will have to be fixed.
Not the compiler itself.

And it's not just GCC.  Almost all programs work this way.



It is a sad fact that many programs /are/ written that way - rushed 
coding under a manager's whip until the code works well enough to pass 
some basic tests, then it is shipped to end users.  Documentation, if 
any, is written afterwards with barely a nod towards a specification.


The /correct/ way to write code is to specify first (as formally and 
thoroughly as appropriate for the project), and have everyone agree that 
the specification fulfils the requirements for the program and that it 
is feasible to implement in practice.  /Then/ start writing code.  If 
the specification is user readable, then it forms the basis for the user 
documentation - if not, then user documentation can be written before, 
during or after code development.


For a living and evolving project like GCC, this all works in lots of 
small steps and in practice changes to the code and changes to the 
documented specifications get committed together, to keep them 
synchronised.  But it is always logically a documented feature and code 
that implements that specification.  (The specification can be a bug 
report, not just the user documentation.)



Attempting to do what you describe - look at the behaviour of gcc in 
practice, document it and call it the specification - would be insane. 
I've already tried to explain on this thread how the logical consequence 
of such ideas is total stagnation of the gcc development.  Look at the 
bugzilla database for GCC - it is /huge/.  Every (valid) bug there is a 
case where GCC does not do what it was supposed to do - what it is 
/documented/ to do.  You would have the GCC folks spend their time 
updating the documentation to redefine these bugs as previously 
undocumented features, rather than fixing the bugs in the code, and 
requiring all future versions of gcc to maintain bug-for-bug 
compatibility with the older versions.


Or could it be that you think this only applies to the features that 
/you/, personally, want to keep?  Sod the rest of the world, as long as 
/you/ don't need to fix your code?



I've come across a fair number of C programmers with your attitude 
before.  Generally they don't realise the 

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Sun, 14 May 2023, 11:21 Jonathan Wakely,  wrote:

>
>
> On Sun, 14 May 2023, 10:47 David Brown,  wrote:
>
>> On 14/05/2023 07:38, Po Lu via Gcc wrote:
>>
>> > No, all you have to do is to tell GNU CC to compile Standard C.  But
>> > what's being debated here is the behavior of GNU CC when translating
>> > both Standard C and GNU C, so your demonstration is almost completely
>> > pointless.
>> >
>> You keep using the term "Standard C", but you are using it incorrectly.
>>
>> "Standard C" means "The language C as recognised by standardisation
>> bodies".  It is, currently, ISO/IEC 9899:2018 - also known as C17/C18.
>> (The standard was completed in C17, but not actually published until C18.)
>>
>> If you want to refer to older standards (or unpublished future
>> standards), you should do so explicitly - C90, C99, C11, C23.
>>
>> Then there are "extended standards" - specific documented extensions on
>> top of an official standard.  "gnu17" would be an example of that.
>>
>> Any language from before the first ANSI C is /not/ standard, since it is
>> not based on any standards document.  The nearest would be the de-facto
>> "standard" (anything "de-facto" is, by definition, not an actual
>> standard) language described in the first edition of "The C Programming
>> Language", and known as "K C".  Many of the C compilers of that time
>> followed the book and implemented - modulo bugs, extensions,
>> inconsistencies, and missing features - the language "K C".  Many also
>> had their own variants, as "C" was already popular before the book was
>> published.
>>
>>
>> So - if you are referring to "K C", then use that term.  It is quite
>> well defined, and accurately describes a popular pre-standard C language.
>>
>> And you may note that if you look at the GCC manual, it supports all
>> standards of C (at least as closely as possible).  All /standards/.
>> "K C" is not a standard, and not officially supported by GCC - there
>> has never, to my knowledge, been any kind of guarantee that GCC would
>> support pre-standard syntax.
>
>
>
> There used to be the -traditional option which was deprecated in gcc 3.1
> and removed in gcc 3.3
>
> https://gcc.gnu.org/gcc-3.1/changes.html
> https://gcc.gnu.org/gcc-3.3/changes.html
>

But even as far back as gcc 2.95.3 that was documented only to "attempt" to
support "some" features of pre -standard C:

"Attempt to support some aspects of traditional C compilers."



>
> There has only been a guarantee that
>> appropriate choices of flags would cause pre-standard syntax to be
>> detected and rejected or diagnosed.  Ironically, the discussion here,
>> with its suggestions of explicit flags to allow "K C" constructs, has
>> come closer to guaranteeing support for that pre-standard dialect than
>> GCC has ever had before.
>>
>> 
>> 
>>
>>
>>
>>
>> (When people refer to "ANSI C", they almost invariably mean the ANSI
>> standard from 1989 that formed, after a bit of section renumbering, ISO
>> C90, it is worth remembering that ANSI actually delegates the C
>> standardisation to ISO.  So "ANSI C" refers to the same language as
>> C17/C18.)
>>
>>
>>

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Sun, 14 May 2023, 10:47 David Brown,  wrote:

> On 14/05/2023 07:38, Po Lu via Gcc wrote:
>
> > No, all you have to do is to tell GNU CC to compile Standard C.  But
> > what's being debated here is the behavior of GNU CC when translating
> > both Standard C and GNU C, so your demonstration is almost completely
> > pointless.
> >
> You keep using the term "Standard C", but you are using it incorrectly.
>
> "Standard C" means "The language C as recognised by standardisation
> bodies".  It is, currently, ISO/IEC 9899:2018 - also known as C17/C18.
> (The standard was completed in C17, but not actually published until C18.)
>
> If you want to refer to older standards (or unpublished future
> standards), you should do so explicitly - C90, C99, C11, C23.
>
> Then there are "extended standards" - specific documented extensions on
> top of an official standard.  "gnu17" would be an example of that.
>
> Any language from before the first ANSI C is /not/ standard, since it is
> not based on any standards document.  The nearest would be the de-facto
> "standard" (anything "de-facto" is, by definition, not an actual
> standard) language described in the first edition of "The C Programming
> Language", and known as "K C".  Many of the C compilers of that time
> followed the book and implemented - modulo bugs, extensions,
> inconsistencies, and missing features - the language "K C".  Many also
> had their own variants, as "C" was already popular before the book was
> published.
>
>
> So - if you are referring to "K C", then use that term.  It is quite
> well defined, and accurately describes a popular pre-standard C language.
>
> And you may note that if you look at the GCC manual, it supports all
> standards of C (at least as closely as possible).  All /standards/.
> "K C" is not a standard, and not officially supported by GCC - there
> has never, to my knowledge, been any kind of guarantee that GCC would
> support pre-standard syntax.



There used to be the -traditional option which was deprecated in gcc 3.1
and removed in gcc 3.3

https://gcc.gnu.org/gcc-3.1/changes.html
https://gcc.gnu.org/gcc-3.3/changes.html

There has only been a guarantee that
> appropriate choices of flags would cause pre-standard syntax to be
> detected and rejected or diagnosed.  Ironically, the discussion here,
> with its suggestions of explicit flags to allow "K C" constructs, has
> come closer to guaranteeing support for that pre-standard dialect than
> GCC has ever had before.
>
> 
> 
>
>
>
>
> (When people refer to "ANSI C", they almost invariably mean the ANSI
> standard from 1989 that formed, after a bit of section renumbering, ISO
> C90, it is worth remembering that ANSI actually delegates the C
> standardisation to ISO.  So "ANSI C" refers to the same language as
> C17/C18.)
>
>
>

Re: More C type errors by default for GCC 14

[David Brown]

On 14/05/2023 07:38, Po Lu via Gcc wrote:


No, all you have to do is to tell GNU CC to compile Standard C.  But
what's being debated here is the behavior of GNU CC when translating
both Standard C and GNU C, so your demonstration is almost completely
pointless.


You keep using the term "Standard C", but you are using it incorrectly.

"Standard C" means "The language C as recognised by standardisation 
bodies".  It is, currently, ISO/IEC 9899:2018 - also known as C17/C18. 
(The standard was completed in C17, but not actually published until C18.)


If you want to refer to older standards (or unpublished future 
standards), you should do so explicitly - C90, C99, C11, C23.


Then there are "extended standards" - specific documented extensions on 
top of an official standard.  "gnu17" would be an example of that.


Any language from before the first ANSI C is /not/ standard, since it is 
not based on any standards document.  The nearest would be the de-facto 
"standard" (anything "de-facto" is, by definition, not an actual 
standard) language described in the first edition of "The C Programming 
Language", and known as "K C".  Many of the C compilers of that time 
followed the book and implemented - modulo bugs, extensions, 
inconsistencies, and missing features - the language "K C".  Many also 
had their own variants, as "C" was already popular before the book was 
published.



So - if you are referring to "K C", then use that term.  It is quite 
well defined, and accurately describes a popular pre-standard C language.


And you may note that if you look at the GCC manual, it supports all 
standards of C (at least as closely as possible).  All /standards/. 
"K C" is not a standard, and not officially supported by GCC - there 
has never, to my knowledge, been any kind of guarantee that GCC would 
support pre-standard syntax.  There has only been a guarantee that 
appropriate choices of flags would cause pre-standard syntax to be 
detected and rejected or diagnosed.  Ironically, the discussion here, 
with its suggestions of explicit flags to allow "K C" constructs, has 
come closer to guaranteeing support for that pre-standard dialect than 
GCC has ever had before.








(When people refer to "ANSI C", they almost invariably mean the ANSI 
standard from 1989 that formed, after a bit of section renumbering, ISO 
C90, it is worth remembering that ANSI actually delegates the C 
standardisation to ISO.  So "ANSI C" refers to the same language as 
C17/C18.)

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Sun, 14 May 2023, 06:28 Po Lu,  wrote:

> Eli Schwartz  writes:
>
> > Quoting my previous reply on the topic.
> >
> > Until everyone is on the same page as you about whether these are GNUC
> > extensions, this conversation will go nowhere.
> >
> > You are of the opinion that "GCC currently behaves a certain way when
> > compiling the code" means that the behavior is documented and specified
> > as a "C Extension" for the GNUC language dialect.
>
> Yes, by the definition of ``extension'' used by everyone except you.
>

Wrong. I wouldn't bother replying to you again in this thread, but I feel
that as a gcc maintainer I should confirm that Eli S. is right here; and
nobody else I know agrees with your definition of extension as "every
non-standard aspect of the compiler's behaviour, whether intentional or
accidental". That's just silly.



> > You've provided some excuses like "C++ is a valid language for writing
> > documentation in, and the HTML docs are lacking", but your arguments are
> > not convincing.
> >
> > GCC has formal documentation. It is written in HTML. If it is lacking,
> > then the only valid move is to improve the HTML documentation and then
> > abide by it. In the absence of documentation, all behavior is, well,
> > "undocumented", which ***definitely*** means it isn't a formal GNUC
> > language dialect extension.
>
> GCC documentation is written in HTML? That's news to me.  I always
> thought it was written in Texinfo.
>

Some is in docbook XML, and some is in HTML (namely the release notes).



> > You can stop arguing your opinions based on what running gcc or g++
> > produces in the form of machine code. What gcc or g++ produces in the
> > form of machine code is not guaranteed even across bugfix releases --
> > your only guarantee is that if it is documented in the ISO standards
> > documents or in the GCC html manual, the produced machine code shall be
> > in accordance with what the documentation says it shall do.
>
> Generated machine code, really?  Not long-standing and observable
> behavior of the translator itself, as has been re-iterated over and over
> again?
>
> > Undefined and undocumented behavior is not a language extension. It is
> > undefined and undocumented behavior.
>
> But when it becomes defined by the translator, in a precise way, it
> becomes an extension to the Standard.
>

No, Eli S. is quite right.


> > You may feel free to take an exact GCC release (source or binary),
> > analyze it, reverse-engineer it, or verify that it does what you want
> > it to do, and then trust that those undefined and undocumented
> > behaviors are ***benevolent***, but that doesn't cause it to be
> > defined and documented, and your trust will, if you are wise, depend
> > on you pinning an exact source code commit of the compiler. Do not
> > depend on bugfix releases of GCC to preserve your undocumented
> > semantics. They may or they may not, but if they don't, it's not a GCC
> > bug, because it is ***undocumented***.
>
> GCC does not implement its documentation.  The documentation is supposed
> to describe (_not_ specify) how GCC behaves, and when the documentation
> is wrong or contains omissions, the documentation will have to be fixed.
> Not the compiler itself.
>

And when the compiler is wrong and the documentation is correct, the
compiler is fixed.



> And it's not just GCC.  Almost all programs work this way.
>

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/14/23 1:28 AM, Po Lu wrote:
>> You may feel free to take an exact GCC release (source or binary),
>> analyze it, reverse-engineer it, or verify that it does what you want
>> it to do, and then trust that those undefined and undocumented
>> behaviors are ***benevolent***, but that doesn't cause it to be
>> defined and documented, and your trust will, if you are wise, depend
>> on you pinning an exact source code commit of the compiler. Do not
>> depend on bugfix releases of GCC to preserve your undocumented
>> semantics. They may or they may not, but if they don't, it's not a GCC
>> bug, because it is ***undocumented***.
> 
> GCC does not implement its documentation.  The documentation is supposed
> to describe (_not_ specify) how GCC behaves, and when the documentation
> is wrong or contains omissions, the documentation will have to be fixed.
> Not the compiler itself.
> 
> And it's not just GCC.  Almost all programs work this way.


But perhaps we can solve this argument.

Please submit a bug report at https://gcc.gnu.org/bugzilla/ to report
that the documentation is wrong or contains omissions, and has to be fixed.

Point out that the C Extensions page omits the documentation on implicit
function declarations and implicit ints. Consider including a patch that
updates https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html to mention
them as well.

If and when this page is updated to document that the compiler's
behavior with these features constitutes a C Extension, then I will
withdraw every comment I have made in this thread.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/14/23 1:28 AM, Po Lu wrote:
>> GCC has formal documentation. It is written in HTML. If it is lacking,
>> then the only valid move is to improve the HTML documentation and then
>> abide by it. In the absence of documentation, all behavior is, well,
>> "undocumented", which ***definitely*** means it isn't a formal GNUC
>> language dialect extension.
> 
> GCC documentation is written in HTML? That's news to me.  I always
> thought it was written in Texinfo.


Does this mean you've conceded the point, and no longer think it is
written in C++?

:)


>> You can stop arguing your opinions based on what running gcc or g++
>> produces in the form of machine code. What gcc or g++ produces in the
>> form of machine code is not guaranteed even across bugfix releases --
>> your only guarantee is that if it is documented in the ISO standards
>> documents or in the GCC html manual, the produced machine code shall be
>> in accordance with what the documentation says it shall do.
> 
> Generated machine code, really?  Not long-standing and observable
> behavior of the translator itself, as has been re-iterated over and over
> again?


You are correct in reading my sentence, that is indeed what I said.

Aside: you have reiterated "the behavior of the translator itself" over
and over again, but it hasn't been generally reiterated, or even iterated.


>> Undefined and undocumented behavior is not a language extension. It is
>> undefined and undocumented behavior.
> 
> But when it becomes defined by the translator, in a precise way, it
> becomes an extension to the Standard.


Repeating this statement won't make it true.


>> You may feel free to take an exact GCC release (source or binary),
>> analyze it, reverse-engineer it, or verify that it does what you want
>> it to do, and then trust that those undefined and undocumented
>> behaviors are ***benevolent***, but that doesn't cause it to be
>> defined and documented, and your trust will, if you are wise, depend
>> on you pinning an exact source code commit of the compiler. Do not
>> depend on bugfix releases of GCC to preserve your undocumented
>> semantics. They may or they may not, but if they don't, it's not a GCC
>> bug, because it is ***undocumented***.
> 
> GCC does not implement its documentation.  The documentation is supposed
> to describe (_not_ specify) how GCC behaves, and when the documentation
> is wrong or contains omissions, the documentation will have to be fixed.
> Not the compiler itself.
> 
> And it's not just GCC.  Almost all programs work this way.


In fact, lots and lots and lots of programs do indeed operate such that
the documentation specifies how the program shall behave, and when the
program fails to behave in the manner in which it is documented to
behave, the program shall be fixed.

We call these failures to behave according to the documentation,


Bugs.


Occasionally it is also called specification-driven development.

...

In cases where the documentation says nothing at all, for good or ill,
the behavior of the program is undefined -- users cannot rely on it, for
they cannot know what is intended and what is not intended -- in this
case, the intended behavior must be defined, documented, and
implemented, and "the program currently does X" gets one vote out of
many and is not guaranteed to get its way.

Very often in such cases the best user-serving thing to do is to define
the behavior as "shall not be used, and for legacy reasons if you use it
it will continue to do X but raise a warning telling you that you are
required to stop depending on it" and possibly even "it may disappear in
semver version YYY".

Sound familiar? A bit like GCC triggering a warning, telling you that
what you're doing is bad and should not be relied on?

But GCC isn't dropping support for it in semver version anything, just
guarding its use behind an opt-in flag.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> GNU C does not define any such thing. It may happen to turn out that
> way, but that is not the same as defining its behavior.

It is.

>> Nor does GCC conform to the Standard by default: while it is okay for a
>> conforming implementation to translate programs relying on implicit int,
>> as there is no way doing so will alter the behavior of any strictly
>> conforming program, it is not okay to reserve keywords such as `asm'.
>> 
>> The following strictly conforming program is thus not acceptable to GCC,
>> unless GCC is operating in standards-conformance mode:
>> 
>>   int
>>   main (argc, argv)
>>   int argc;
>>   char **argv;
>>   {
>> int asm;
>> return asm = 0;
>>   }
>> 
>> which shows that debating features based on the Standard is entirely
>> pointless, as the Standard allows implementations to provide almost
>> anything it prohibits.
>
>
> Sure, all I have to do is tell GCC to act like a C compiler.
>
>
> $ gcc -std=c2x /tmp/po.c -o /tmp/po; /tmp/po; echo $?
> /tmp/po.c: In function ‘main’:
> /tmp/po.c:2:3: warning: old-style function definition
> [-Wold-style-definition]
> 2 |   main (argc, argv)
>   |   ^~~~
> 0

No, all you have to do is to tell GNU CC to compile Standard C.  But
what's being debated here is the behavior of GNU CC when translating
both Standard C and GNU C, so your demonstration is almost completely
pointless.

Btw, try to compile any program using inline assembler, and you will
quickly find out how many programs depend on the (gasp!) non-conformant
behavior of GNU C.

> But I don't understand what point you are trying to make, anyway. The
> Standard allows, but does not require, implementations to do many things
> if it so chooses. GNUC takes advantage of this when operating in GNUC
> mode, when also documenting GNUC features in the HTML docs.

[...]

> What does this have to do with implicit-int, which is a constraint
> violation? Where in the GNUC html documentation does it say that
> constraint violations applied to Type specifiers have been carved out as
> a GNUC extension?

As I said, what the Info documentation does not say is completely
irrelevant.  I might as well ask you: where in (gcc)C Extensions is it
said that the documentation describes each and every extension and
aspect of GNU C?

The documentation is supposed to describe the behavior of the
translator, not to specify it.

> It's not a GNUC extension, you cannot assume it will work. It might work
> anyway, but that's a matter of luck.

It _is_, regardless of what you might say.

> It is unclear why you are overly focused on implicit-int, to be honest.

Because there is a point to be made for discouraging implicit function
declarations.  Certainly not enough to make them errors in GNU C, but
enough to justify their obsolescence in the ANSI Standard.

There is none whatsoever for discouraging implicit int.  Its
obsolescence and later removal was simply the act of a overzealous
Committee, deviating too far from its task of standardizing existing
practice.

> But your arguments in favor of implicit-int aren't very compelling either.

Tell me how?

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> Quoting my previous reply on the topic.
>
> Until everyone is on the same page as you about whether these are GNUC
> extensions, this conversation will go nowhere.
>
> You are of the opinion that "GCC currently behaves a certain way when
> compiling the code" means that the behavior is documented and specified
> as a "C Extension" for the GNUC language dialect.

Yes, by the definition of ``extension'' used by everyone except you.

> You've provided some excuses like "C++ is a valid language for writing
> documentation in, and the HTML docs are lacking", but your arguments are
> not convincing.
>
> GCC has formal documentation. It is written in HTML. If it is lacking,
> then the only valid move is to improve the HTML documentation and then
> abide by it. In the absence of documentation, all behavior is, well,
> "undocumented", which ***definitely*** means it isn't a formal GNUC
> language dialect extension.

GCC documentation is written in HTML? That's news to me.  I always
thought it was written in Texinfo.

> You can stop arguing your opinions based on what running gcc or g++
> produces in the form of machine code. What gcc or g++ produces in the
> form of machine code is not guaranteed even across bugfix releases --
> your only guarantee is that if it is documented in the ISO standards
> documents or in the GCC html manual, the produced machine code shall be
> in accordance with what the documentation says it shall do.

Generated machine code, really?  Not long-standing and observable
behavior of the translator itself, as has been re-iterated over and over
again?

> Undefined and undocumented behavior is not a language extension. It is
> undefined and undocumented behavior.

But when it becomes defined by the translator, in a precise way, it
becomes an extension to the Standard.

> You may feel free to take an exact GCC release (source or binary),
> analyze it, reverse-engineer it, or verify that it does what you want
> it to do, and then trust that those undefined and undocumented
> behaviors are ***benevolent***, but that doesn't cause it to be
> defined and documented, and your trust will, if you are wise, depend
> on you pinning an exact source code commit of the compiler. Do not
> depend on bugfix releases of GCC to preserve your undocumented
> semantics. They may or they may not, but if they don't, it's not a GCC
> bug, because it is ***undocumented***.

GCC does not implement its documentation.  The documentation is supposed
to describe (_not_ specify) how GCC behaves, and when the documentation
is wrong or contains omissions, the documentation will have to be fixed.
Not the compiler itself.

And it's not just GCC.  Almost all programs work this way.

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/13/23 1:53 AM, Po Lu wrote:
> There are no ``errors'' in Standard C (with the possible exception of
> the #error preprocessing directive), only constraint and syntax rule
> violations.  Such violations are required to generate diagnostic
> messages, after which the behavior of the translator ceases to be
> defined by the Standard, but GNU C defines it to mean that the type is
> int.


GNU C does not define any such thing. It may happen to turn out that
way, but that is not the same as defining its behavior.


> Nor does GCC conform to the Standard by default: while it is okay for a
> conforming implementation to translate programs relying on implicit int,
> as there is no way doing so will alter the behavior of any strictly
> conforming program, it is not okay to reserve keywords such as `asm'.
> 
> The following strictly conforming program is thus not acceptable to GCC,
> unless GCC is operating in standards-conformance mode:
> 
>   int
>   main (argc, argv)
>   int argc;
>   char **argv;
>   {
> int asm;
> return asm = 0;
>   }
> 
> which shows that debating features based on the Standard is entirely
> pointless, as the Standard allows implementations to provide almost
> anything it prohibits.


Sure, all I have to do is tell GCC to act like a C compiler.


$ gcc -std=c2x /tmp/po.c -o /tmp/po; /tmp/po; echo $?
/tmp/po.c: In function ‘main’:
/tmp/po.c:2:3: warning: old-style function definition
[-Wold-style-definition]
2 |   main (argc, argv)
  |   ^~~~
0


But I don't understand what point you are trying to make, anyway. The
Standard allows, but does not require, implementations to do many things
if it so chooses. GNUC takes advantage of this when operating in GNUC
mode, when also documenting GNUC features in the HTML docs.


What does this have to do with implicit-int, which is a constraint
violation? Where in the GNUC html documentation does it say that
constraint violations applied to Type specifiers have been carved out as
a GNUC extension?

It's not a GNUC extension, you cannot assume it will work. It might work
anyway, but that's a matter of luck.


> So I ask you again: what is unclear about declarations which are
> implicitly int, in a way that is likely to cause program errors?

It is unclear why you are overly focused on implicit-int, to be honest.

But your arguments in favor of implicit-int aren't very compelling either.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/12/23 8:45 PM, Po Lu wrote:
> Gabriel Ravier  writes:
> 
>> ...You're joking, right ? You can't possibly be seriously arguing
>> this, you have to be kidding... right ?
> 
> No, I'm not.  The meaning of a variable declaration with only a storage
> class specifier is extremely clear: the type of the variable is `int'.
> There's absolutely nothing ambiguous about it whatsoever:


Quoting my previous reply on the topic.

Until everyone is on the same page as you about whether these are GNUC
extensions, this conversation will go nowhere.

You are of the opinion that "GCC currently behaves a certain way when
compiling the code" means that the behavior is documented and specified
as a "C Extension" for the GNUC language dialect.

You've provided some excuses like "C++ is a valid language for writing
documentation in, and the HTML docs are lacking", but your arguments are
not convincing.

GCC has formal documentation. It is written in HTML. If it is lacking,
then the only valid move is to improve the HTML documentation and then
abide by it. In the absence of documentation, all behavior is, well,
"undocumented", which ***definitely*** means it isn't a formal GNUC
language dialect extension.

You can stop arguing your opinions based on what running gcc or g++
produces in the form of machine code. What gcc or g++ produces in the
form of machine code is not guaranteed even across bugfix releases --
your only guarantee is that if it is documented in the ISO standards
documents or in the GCC html manual, the produced machine code shall be
in accordance with what the documentation says it shall do.

Undefined and undocumented behavior is not a language extension. It is
undefined and undocumented behavior. You may feel free to take an exact
GCC release (source or binary), analyze it, reverse-engineer it, or
verify that it does what you want it to do, and then trust that those
undefined and undocumented behaviors are ***benevolent***, but that
doesn't cause it to be defined and documented, and your trust will, if
you are wise, depend on you pinning an exact source code commit of the
compiler. Do not depend on bugfix releases of GCC to preserve your
undocumented semantics. They may or they may not, but if they don't,
it's not a GCC bug, because it is ***undocumented***.

...

So in answer to your question, the meaning of such a variable
declaration is very much unclear -- C specifies one thing, GNUC doesn't
specify *anything*, and actually executing the gcc compiler frontend
tool will do... something.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Thomas Koenig  writes:

> C99, 6.7.2, "Type specifiers"
>
> # Constraints
>
> # At least one type specifier shall be given in the declaration
> # specifiers in each declaration, and in the specifier-qualifier
> # list in each struct declaration and type name.

And?

> In C99 and onwards, this is an error (a violation of a "shall"
> directive).

There are no ``errors'' in Standard C (with the possible exception of
the #error preprocessing directive), only constraint and syntax rule
violations.  Such violations are required to generate diagnostic
messages, after which the behavior of the translator ceases to be
defined by the Standard, but GNU C defines it to mean that the type is
int.

Nor does GCC conform to the Standard by default: while it is okay for a
conforming implementation to translate programs relying on implicit int,
as there is no way doing so will alter the behavior of any strictly
conforming program, it is not okay to reserve keywords such as `asm'.

The following strictly conforming program is thus not acceptable to GCC,
unless GCC is operating in standards-conformance mode:

  int
  main (argc, argv)
  int argc;
  char **argv;
  {
int asm;
return asm = 0;
  }

which shows that debating features based on the Standard is entirely
pointless, as the Standard allows implementations to provide almost
anything it prohibits.

So I ask you again: what is unclear about declarations which are
implicitly int, in a way that is likely to cause program errors?

Re: More C type errors by default for GCC 14

[Thomas Koenig via Gcc]

On 13.05.23 02:45, Po Lu via Gcc wrote:

Gabriel Ravier  writes:


...You're joking, right ? You can't possibly be seriously arguing
this, you have to be kidding... right ?


No, I'm not.  The meaning of a variable declaration with only a storage
class specifier is extremely clear: the type of the variable is `int'.


C99, 6.7.2, "Type specifiers"

# Constraints

# At least one type specifier shall be given in the declaration
# specifiers in each declaration, and in the specifier-qualifier
# list in each struct declaration and type name.


There's absolutely nothing ambiguous about it whatsoever:


In C99 and onwards, this is an error (a violation of a "shall"
directive).


   register i;
   extern   limit, *k, do_some_computation ();

   for (i = 0; i < limit; ++i)
 k[i] = do_some_computation (i);

Please try to prove me wrong.


Happy to oblige.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Gabriel Ravier  writes:

> ...You're joking, right ? You can't possibly be seriously arguing
> this, you have to be kidding... right ?

No, I'm not.  The meaning of a variable declaration with only a storage
class specifier is extremely clear: the type of the variable is `int'.
There's absolutely nothing ambiguous about it whatsoever:

  register i;
  extern   limit, *k, do_some_computation ();

  for (i = 0; i < limit; ++i)
k[i] = do_some_computation (i);

Please try to prove me wrong.

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Sam James:

> Florian Weimer  writes:
>
>> * Sam James:
>>
>>> Florian Weimer  writes:
>>>
 [...]
 In summary, all these seems to be good candidates for errors by default:

 * int-conversion as errors (already raised separately
 * -Wint-conversion for ?:
 * parameter names in non-prototype function declarations
 * the union wait function pointer compatibility kludge
 * return-with-out-value for non-void functions
 * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)

 This are more “maybe“:

 * incompatible-pointer-types as errors (already raised separately)
 * int-conversion and incompatible-pointer-types in comparisons
 * return with value in a function returning void
>>>
>>> -Wreturn-type tends to bite people with C++.
>>
>> Sorry, what do you mean?
>
> Falling off the end of a function in C++ is UB and people fall
> victim to it often, but in C, it's only UB if you try to use
> its return value.
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364 is one
> example of many.
>
> What I meant was: I see this a lot in C++ and sometimes in C
> but it's usually trivial to fix, even if it's less harmful
> for some of the instances.

Ohh, I was thinking just about the -Wreturn-type issues for return
statements (value vs no value), not “control reaches end of non-void
function”.  That's a separate issue, and yes, it's more confusing for
C++ due to undefined behavior back-propagation within the same
function.

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Florian Weimer  writes:

> * Sam James:
>
>> Florian Weimer  writes:
>>
>>> [...]
>>> In summary, all these seems to be good candidates for errors by default:
>>>
>>> * int-conversion as errors (already raised separately
>>> * -Wint-conversion for ?:
>>> * parameter names in non-prototype function declarations
>>> * the union wait function pointer compatibility kludge
>>> * return-with-out-value for non-void functions
>>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>>>
>>> This are more “maybe“:
>>>
>>> * incompatible-pointer-types as errors (already raised separately)
>>> * int-conversion and incompatible-pointer-types in comparisons
>>> * return with value in a function returning void
>>
>> -Wreturn-type tends to bite people with C++.
>
> Sorry, what do you mean?

Falling off the end of a function in C++ is UB and people fall
victim to it often, but in C, it's only UB if you try to use
its return value.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109364 is one
example of many.

What I meant was: I see this a lot in C++ and sometimes in C
but it's usually trivial to fix, even if it's less harmful
for some of the instances.

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Sam James:

> Florian Weimer  writes:
>
>> [...]
>> In summary, all these seems to be good candidates for errors by default:
>>
>> * int-conversion as errors (already raised separately
>> * -Wint-conversion for ?:
>> * parameter names in non-prototype function declarations
>> * the union wait function pointer compatibility kludge
>> * return-with-out-value for non-void functions
>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>>
>> This are more “maybe“:
>>
>> * incompatible-pointer-types as errors (already raised separately)
>> * int-conversion and incompatible-pointer-types in comparisons
>> * return with value in a function returning void
>
> -Wreturn-type tends to bite people with C++.

Sorry, what do you mean?

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Florian Weimer  writes:

> [...]
> In summary, all these seems to be good candidates for errors by default:
>
> * int-conversion as errors (already raised separately
> * -Wint-conversion for ?:
> * parameter names in non-prototype function declarations
> * the union wait function pointer compatibility kludge
> * return-with-out-value for non-void functions
> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>
> This are more “maybe“:
>
> * incompatible-pointer-types as errors (already raised separately)
> * int-conversion and incompatible-pointer-types in comparisons
> * return with value in a function returning void

-Wreturn-type tends to bite people with C++. Obviously the behaviour
is different for C, but it's a serious code smell. I've been playing
with it for C for a while and I don't get that many hits with it of
this type.

> * dereferencing void *
> * taking the address of void

I think I've seen these but they've been accompanied by other issues.

> * "function types not truly compatible in ISO C"
>   and "types are not quite compatible" (depending on what they actually mean)
> * qualifier mismatches (may need separate opt-out)

This has been common for func. ptrs. but not too bad. I haven't
got any data on other cases but am a bit worried about how noisy it'll
be for those.

> * sign mismatches in pointers (definitely needs separate opt-out)
>


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Florian Weimer  writes:

> * Jason Merrill:
>
>> On Fri, May 12, 2023 at 11:03 AM Florian Weimer  wrote:
>>>
>>> * Joseph Myers:
>>>
>>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>>> >
>>> >> That is not the case we are discussing, AFAIU.  Or at least no one has
>>> >> yet explained why accepting those old K programs will adversely
>>> >> affect the ability of GCC to compile C2x programs.
>>> >
>>> > At block scope,
>>> >
>>> >   auto x = 1.5;
>>> >
>>> > declares x to have type double in C2x (C++-style auto), but type int in
>>> > C89 (and is invalid for versions in between).  In this case, there is an
>>> > incompatible semantic change between implicit int and C++-style auto.
>>> > Giving an error before we make -std=gnu2x the default seems like a
>>> > particularly good idea, to further alert anyone who has been ignoring the
>>> > warnings about implicit int that semantics will change incompatibly.
>>>
>>> Obviously makes sense to me.
>>
>> Agreed.  But we could safely continue to accept
>>
>>   static x = 42;
>>
>> or even
>>
>>   auto x = 42; // meaning of 'auto' changes, meaning of the declaration does 
>> not
>>
>> We might make -Wimplicit-int an error by default only if the
>> initializer has a type other than 'int'.
>
> Based on what I saw fixing Fedora, these cases are not very common.
> Sure, sometimes common program such as valgrind have an instance
> , but that's really an
> exception.
>
> Implicit int is common as the return type of main (especially in
> autoconf tests), and due to a missing declaration list entry of an
> old-style function definition.  The main case could be treated as an
> exception.  The old-style function definition case is a common source
> of bugs and therefore worth fixing.  The addition of unnamed function
> parameters as an extension actually created a new class of bugs here
> (a typo in the type name of a single unnamed parameter results in an
> old-style function definition by accident).
>
>>> > In cases where the standard requires a diagnostic, some are errors, some
>>> > are pedwarns-by-default or unconditional pedwarns, some are
>>> > pedwarns-if-pedantic - the choice depending on how suspicious the
>>> > construct in question is and whether it corresponds to a meaningful
>>> > extension (this is not making an automatic choice for every such situation
>>> > in the standard, it's a case-by-case judgement by maintainers).  By now,
>>> > the cases discussed in this thread are sufficiently suspicious -
>>> > sufficiently likely to result in unintended execution at runtime (not, of
>>> > course, reliably detected because programs with such dodgy code are very
>>> > unlikely to have thorough automated tests covering all their code) - that
>>> > is it in the interests of users for them to be errors by default (for C99
>>> > and later modes, in the cases that were valid in C89).
>>>
>>> Just to recap, those are controlled by
>>> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
>>> -Wincompatible-pointer-types, roughly in increasing order of
>>> compatibility impact with old sources.
>>
>> What would the impact be of making -Wint-conversion an error by
>> default only if the types are different sizes?
>
> From a distribution perspective, it does not change anything because
> we build everything on 64-bit anyway.  Unlike e.g. Fedora, Debian
> doesn't require all builds to succeed before the new package can be
> installed, but given that the primary targets are 64 bit, I don't
> think a restricted -Wint-conversion error would be much of a
> simplification.  The target-dependent nature of the warning is
> probably more confusing.

I don't see us really gaining anything from restricting it. Like you
said, the cases in the wild are actually all of the same "class".


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Jason Merrill:

> On Fri, May 12, 2023 at 11:03 AM Florian Weimer  wrote:
>>
>> * Joseph Myers:
>>
>> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>> >
>> >> That is not the case we are discussing, AFAIU.  Or at least no one has
>> >> yet explained why accepting those old K programs will adversely
>> >> affect the ability of GCC to compile C2x programs.
>> >
>> > At block scope,
>> >
>> >   auto x = 1.5;
>> >
>> > declares x to have type double in C2x (C++-style auto), but type int in
>> > C89 (and is invalid for versions in between).  In this case, there is an
>> > incompatible semantic change between implicit int and C++-style auto.
>> > Giving an error before we make -std=gnu2x the default seems like a
>> > particularly good idea, to further alert anyone who has been ignoring the
>> > warnings about implicit int that semantics will change incompatibly.
>>
>> Obviously makes sense to me.
>
> Agreed.  But we could safely continue to accept
>
>   static x = 42;
>
> or even
>
>   auto x = 42; // meaning of 'auto' changes, meaning of the declaration does 
> not
>
> We might make -Wimplicit-int an error by default only if the
> initializer has a type other than 'int'.

Based on what I saw fixing Fedora, these cases are not very common.
Sure, sometimes common program such as valgrind have an instance
, but that's really an
exception.

Implicit int is common as the return type of main (especially in
autoconf tests), and due to a missing declaration list entry of an
old-style function definition.  The main case could be treated as an
exception.  The old-style function definition case is a common source
of bugs and therefore worth fixing.  The addition of unnamed function
parameters as an extension actually created a new class of bugs here
(a typo in the type name of a single unnamed parameter results in an
old-style function definition by accident).

>> > In cases where the standard requires a diagnostic, some are errors, some
>> > are pedwarns-by-default or unconditional pedwarns, some are
>> > pedwarns-if-pedantic - the choice depending on how suspicious the
>> > construct in question is and whether it corresponds to a meaningful
>> > extension (this is not making an automatic choice for every such situation
>> > in the standard, it's a case-by-case judgement by maintainers).  By now,
>> > the cases discussed in this thread are sufficiently suspicious -
>> > sufficiently likely to result in unintended execution at runtime (not, of
>> > course, reliably detected because programs with such dodgy code are very
>> > unlikely to have thorough automated tests covering all their code) - that
>> > is it in the interests of users for them to be errors by default (for C99
>> > and later modes, in the cases that were valid in C89).
>>
>> Just to recap, those are controlled by
>> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
>> -Wincompatible-pointer-types, roughly in increasing order of
>> compatibility impact with old sources.
>
> What would the impact be of making -Wint-conversion an error by
> default only if the types are different sizes?

>From a distribution perspective, it does not change anything because
we build everything on 64-bit anyway.  Unlike e.g. Fedora, Debian
doesn't require all builds to succeed before the new package can be
installed, but given that the primary targets are 64 bit, I don't
think a restricted -Wint-conversion error would be much of a
simplification.  The target-dependent nature of the warning is
probably more confusing.

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Joseph Myers:

> On Fri, 12 May 2023, Florian Weimer wrote:
>
>> This sone seems to be a good candidate for additional errors, though:
>> 
>>   warned_here = pedwarn
>> (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
>>  "% with no value, in function returning non-void");
>> 
>> It's a clear type volation that can lead to obscure bugs.  Maybe the
>> converse as well.
>
> This one is valid before C99 (the pedwarn is conditional on flag_isoc99, 
> otherwise it's a warning).

Ahh, I see now, this is required for making “return;” work in
functions returning an implied int type.  So it's tied to implicit-int
removal.  I'm going to add checking this to a future run.

> The converse is unconditionally invalid 
> (though the case where the returned expression from the function with void 
> return type itself has void type is valid in C++ and only a 
> pedwarn-if-pedantic for C; that case is a reasonable extension).

Agreed.

Thanks,
Florian

Re: More C type errors by default for GCC 14

[Jason Merrill via Gcc]

On Fri, May 12, 2023 at 11:03 AM Florian Weimer  wrote:
>
> * Joseph Myers:
>
> > On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
> >
> >> That is not the case we are discussing, AFAIU.  Or at least no one has
> >> yet explained why accepting those old K programs will adversely
> >> affect the ability of GCC to compile C2x programs.
> >
> > At block scope,
> >
> >   auto x = 1.5;
> >
> > declares x to have type double in C2x (C++-style auto), but type int in
> > C89 (and is invalid for versions in between).  In this case, there is an
> > incompatible semantic change between implicit int and C++-style auto.
> > Giving an error before we make -std=gnu2x the default seems like a
> > particularly good idea, to further alert anyone who has been ignoring the
> > warnings about implicit int that semantics will change incompatibly.
>
> Obviously makes sense to me.

Agreed.  But we could safely continue to accept

  static x = 42;

or even

  auto x = 42; // meaning of 'auto' changes, meaning of the declaration does not

We might make -Wimplicit-int an error by default only if the
initializer has a type other than 'int'.

> > In cases where the standard requires a diagnostic, some are errors, some
> > are pedwarns-by-default or unconditional pedwarns, some are
> > pedwarns-if-pedantic - the choice depending on how suspicious the
> > construct in question is and whether it corresponds to a meaningful
> > extension (this is not making an automatic choice for every such situation
> > in the standard, it's a case-by-case judgement by maintainers).  By now,
> > the cases discussed in this thread are sufficiently suspicious -
> > sufficiently likely to result in unintended execution at runtime (not, of
> > course, reliably detected because programs with such dodgy code are very
> > unlikely to have thorough automated tests covering all their code) - that
> > is it in the interests of users for them to be errors by default (for C99
> > and later modes, in the cases that were valid in C89).
>
> Just to recap, those are controlled by
> -Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
> -Wincompatible-pointer-types, roughly in increasing order of
> compatibility impact with old sources.

What would the impact be of making -Wint-conversion an error by
default only if the types are different sizes?

Jason

Re: More C type errors by default for GCC 14

[Joseph Myers]

On Fri, 12 May 2023, Florian Weimer wrote:

> This sone seems to be a good candidate for additional errors, though:
> 
>   warned_here = pedwarn
> (loc, warn_return_type >= 0 ? OPT_Wreturn_type : 0,
>  "% with no value, in function returning non-void");
> 
> It's a clear type volation that can lead to obscure bugs.  Maybe the
> converse as well.

This one is valid before C99 (the pedwarn is conditional on flag_isoc99, 
otherwise it's a warning).  The converse is unconditionally invalid 
(though the case where the returned expression from the function with void 
return type itself has void type is valid in C++ and only a 
pedwarn-if-pedantic for C; that case is a reasonable extension).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Alexander Monakov:

> This is not valid (constraint violation):
>
>   unsigned x;
>
>   int *p = 
>
> In GCC this is diagnosed under -Wpointer-sign:
>
>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892

Thanks for the reference.  I filed:

  -Wpointer-sign must be enabled by default
  

Re: More C type errors by default for GCC 14

[Alexander Monakov via Gcc]

On Fri, 12 May 2023, Gabriel Ravier via Gcc wrote:

> On 5/12/23 19:52, Florian Weimer wrote:
> > I think we have another problem.
> >
> > We do not warn by default for:
> >
> >int x;
> >unsigned *p;
> >
> >p = 
> >
> > Isn't that a conformance issue because the pointers are incompatible,
> > requiring a diagnostic?
> >
> > Furthermore, Unlike the char case, this tends to introduce
> > strict-aliasing violations, so there is a good reason to treat this
> > variant as an error (even if we would only warn for char * and
> > unsigned char *).
> 
> Isn't this allowed by the standard ? 6.5.7. Expressions states:
> > An object shall have its stored value accessed only by an lvalue 
> expression that has one of thefollowing types:[...] - a type that is the
> signed or unsigned type corresponding to the effective type of the object

The standard allows aliasing, but not assigning pointers without a cast.

This is valid:

  unsigned x;

  int *p = (void *)

  *p = 0;

This is not valid (constraint violation):

  unsigned x;

  int *p = 

In GCC this is diagnosed under -Wpointer-sign:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25892

Alexander

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Gabriel Ravier:

> On 5/12/23 19:52, Florian Weimer wrote:
>> * Florian Weimer:
>>
>>> In summary, all these seems to be good candidates for errors by default:
>>>
>>> * int-conversion as errors (already raised separately
>>> * -Wint-conversion for ?:
>>> * parameter names in non-prototype function declarations
>>> * the union wait function pointer compatibility kludge
>>> * return-with-out-value for non-void functions
>>> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)
>> I think we have another problem.
>>
>> We do not warn by default for:
>>
>>int x;
>>unsigned *p;
>>
>>p = 
>>
>> Isn't that a conformance issue because the pointers are incompatible,
>> requiring a diagnostic?
>>
>> Furthermore, Unlike the char case, this tends to introduce
>> strict-aliasing violations, so there is a good reason to treat this
>> variant as an error (even if we would only warn for char * and
>> unsigned char *).
>
> Isn't this allowed by the standard ? 6.5.7. Expressions states:
>  > An object shall have its stored value accessed only by an lvalue 
> expression that has one of thefollowing types:[...] - a type that is the 
> signed or unsigned type corresponding to the effective type of the object

Ahh, so no strict aliasing violation at least.

Still I think we are required to diagnose the constraint violation in
the pointer assignment.  (Cerberus quotes C11 §6.5.16.1#1, bullet 3
and 4 as violation.)

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/12/23 19:52, Florian Weimer wrote:

* Florian Weimer:


In summary, all these seems to be good candidates for errors by default:

* int-conversion as errors (already raised separately
* -Wint-conversion for ?:
* parameter names in non-prototype function declarations
* the union wait function pointer compatibility kludge
* return-with-out-value for non-void functions
* -Wincomatible-pointer-types warning for ?: (but no error yet, see below)

I think we have another problem.

We do not warn by default for:

   int x;
   unsigned *p;

   p = 

Isn't that a conformance issue because the pointers are incompatible,
requiring a diagnostic?

Furthermore, Unlike the char case, this tends to introduce
strict-aliasing violations, so there is a good reason to treat this
variant as an error (even if we would only warn for char * and
unsigned char *).


Isn't this allowed by the standard ? 6.5.7. Expressions states:
> An object shall have its stored value accessed only by an lvalue 
expression that has one of thefollowing types:[...] - a type that is the 
signed or unsigned type corresponding to the effective type of the object

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Florian Weimer:

> In summary, all these seems to be good candidates for errors by default:
>
> * int-conversion as errors (already raised separately
> * -Wint-conversion for ?:
> * parameter names in non-prototype function declarations
> * the union wait function pointer compatibility kludge
> * return-with-out-value for non-void functions
> * -Wincomatible-pointer-types warning for ?: (but no error yet, see below)

I think we have another problem.

We do not warn by default for:

  int x;
  unsigned *p;

  p = 

Isn't that a conformance issue because the pointers are incompatible,
requiring a diagnostic?

Furthermore, Unlike the char case, this tends to introduce
strict-aliasing violations, so there is a good reason to treat this
variant as an error (even if we would only warn for char * and
unsigned char *).

Re: More C type errors by default for GCC 14

[Jason Merrill via Gcc]

On Fri, May 12, 2023 at 9:20 AM Po Lu via Gcc  wrote:
> Yes, just these quotes from a former GCC maintainer:
>
>   In C, we cannot divide all user code into "right" and "wrong" in this
>   kind of simple way, and certainly not based on the ISO standard.  That
>   standard is just the decisions of a certain committee (which I was a
>   member of) about what cases conforming compilers should commit to
>   support.  We must not let ourselves start thinking that C code is
>   "wrong", just because it is not conforming ISO C code.
>
>   C programs use many cases that are not conforming, but do work.  This
>   will be true for as long as C is used, because changing it would
>   require major changes in the C language.
>
>   From time to time, there is a real *need* to make some of these cases
>   stop working, for the sake of some benefit that users want.  When this
>   happens, we should do it; the user community will accept it, because
>   they will see that it is being done for their sake.  Some will
>   grumble, but the users who appreciate the benefits will convince them.
>
>   But when there is no *need* to break these cases, when we can keep
>   them working fairly easily, we should keep them working.  If we break
>   them unnecessarily, we invite the legitimate anger of the users.

Absolutely.  The debate is really over the degree of "need" and the
degree of "break".

The proposal argues that the need is to help developers using GCC
avoid a common class of wrong-code bugs that have gotten worse with
the rise of platforms with 64-bit pointers and 32-bit int, and even
more with the adoption of position-independent executables as a
security measure.

The "break" is asking affected legacy code to adjust build flags, if
they don't want to adjust their code.

Note that some such legacy code does in fact need to be fixed to work
properly on modern systems, e.g.
https://developers.redhat.com/blog/2019/04/22/implicit-function-declarations-flexs-use-of-reallocarray

Certainly there are people in both camps with valid perspectives, as
Florian pointed out early in his initial email.  Previously, we've
leaned toward the second camp for these particular issues.  But the
problem above strengthens the case of the first camp. And the
dwindling amount of affected code weakens the case of the second camp.
And so the proposal suggests that we change the default behavior.

As a compromise, it should be possible to error by default only in
cases where the implicit int (including as a return value) is either
the source or target of a non-value-preserving conversion, as those
are very likely to be bugs.  That seems desirable for both camps.

A simpler change to catch this particular bug would be to make
-Wint-conversion an error by default iff the sizes differ.

(Incidentally, for the first camp, it seems desirable to have a flag
to upgrade all currently enabled pedwarns to errors without also
enabling pedwarns that depend on -pedantic/-Wpedantic;
-pedantic-errors does both; -Werror=pedantic makes only the latter set
errors, which seems unlikely to be useful to anyone.)

Jason

Re: More C type errors by default for GCC 14

[Florian Weimer]

* Joseph Myers:

> On Wed, 10 May 2023, Eli Zaretskii via Gcc wrote:
>
>> That is not the case we are discussing, AFAIU.  Or at least no one has
>> yet explained why accepting those old K programs will adversely
>> affect the ability of GCC to compile C2x programs.
>
> At block scope,
>
>   auto x = 1.5;
>
> declares x to have type double in C2x (C++-style auto), but type int in 
> C89 (and is invalid for versions in between).  In this case, there is an 
> incompatible semantic change between implicit int and C++-style auto.  
> Giving an error before we make -std=gnu2x the default seems like a 
> particularly good idea, to further alert anyone who has been ignoring the 
> warnings about implicit int that semantics will change incompatibly.

Obviously makes sense to me.

> In cases where the standard requires a diagnostic, some are errors, some 
> are pedwarns-by-default or unconditional pedwarns, some are 
> pedwarns-if-pedantic - the choice depending on how suspicious the 
> construct in question is and whether it corresponds to a meaningful 
> extension (this is not making an automatic choice for every such situation 
> in the standard, it's a case-by-case judgement by maintainers).  By now, 
> the cases discussed in this thread are sufficiently suspicious - 
> sufficiently likely to result in unintended execution at runtime (not, of 
> course, reliably detected because programs with such dodgy code are very 
> unlikely to have thorough automated tests covering all their code) - that 
> is it in the interests of users for them to be errors by default (for C99 
> and later modes, in the cases that were valid in C89).

Just to recap, those are controlled by
-Wimplicit-function-declaration, -Wimplicit-int, -Wint-conversion, and
-Wincompatible-pointer-types, roughly in increasing order of
compatibility impact with old sources.

> It might also make sense to review other pedwarns-by-default and 
> unconditional pedwarns to consider if any of those should be errors by 
> default, though I suspect most of those are less significant.

I went through the pedwarn calls in the C front end.

First, these two appear to be genuine bugs:

  Incompatible pointer types in ?: not covered by -Wincompatible-pointer-types
  

  Pointer/integer mismatch in ?: not covered by -Wint-conversion
  location, OPT_Wpedantic,
   "obsolete use of designated initializer without %<=%>");

Unclear whether we still need to support that, but also harmless, I
guess.)


This one seems to be hack to support obsolete wait function usage.  We
probably don't need it any more because the union wait was removed
from glibc 2.24, and the function prototypes in glibc are now more
standard.  The union wait type was deprecated in the early 90s.

  /* Given  wait (union {union wait *u; int *i} *)
 and  wait (union wait *),
 prefer  union wait *  as type of parm.  */
   pedwarn (input_location, OPT_Wpedantic,
"function types not truly compatible in ISO C")

And furher below in c-typeck.cc:

  /* Allow  wait (union {union wait *u; int *i} *)
 and  wait (union wait *)  to be compatible.  */

I think it should be safe to error for these by default.


I couldn't figure out what these warnings are about:

  pedwarn (input_location, OPT_Wpedantic,
   "function types not truly compatible in ISO C");
  pedwarn (location, OPT_Wpedantic, "types are not quite compatible");


This seems to be mainly for &*p if p is of type void *:

  

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Fri, 12 May 2023 at 14:54, Po Lu via Gcc  wrote:
> From my perspective, I also see only a few extremely loud people
> repeating the same arguments over and over.

Maybe stop then?

> But how many times have I
> mentioned that?  The number of people in this thread is too small to
> conclude anything from.

Maybe if you were quieter yourself you'd see more replies in favour
from different people:

https://gcc.gnu.org/pipermail/gcc/2023-May/241434.html
https://gcc.gnu.org/pipermail/gcc/2023-May/241424.html
https://gcc.gnu.org/pipermail/gcc/2023-May/241475.html
https://gcc.gnu.org/pipermail/gcc/2023-May/241384.html
https://gcc.gnu.org/pipermail/gcc/2023-May/241308.html

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Gabriel Ravier  writes:

> As somebody that spends a lot of time helping beginners, yes,
> constantly. I'd go as far as to say it's an error that seemingly
> everyone has made at least once.

Really?  And after making this mistake (and learning its solution), did
they continue to make the same mistake?

Because I don't see why it's a good idea to expect people who have just
begun learning C to immediately be able to write correct code.

BTW, please don't quote the parts of of an article which you are not
responding to.  Especially not excessively so, which you just did.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> This sounds like a "you" problem.

I don't write these Makefiles.  Others do.
It wasn't the problem of their authors before, so why should it be now?

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Gabriel Ravier  writes:

> It's "extra work" to add 10 characters to a Makefile, but normal to
> add random faulty declarations everywhere ? 

You're assuming that people are willing to edit Makefiles, which is all
kinds of pain, and then put up with a complete recompile of whatever
software is being built because CFLAGS changed.

> I could only imagine someone doing this if they're being either
> extremely uninformed, extremely restricted (e.g. no change to any
> configuration files, no pragmas to disable the errors and not even
> having 10 seconds to look up the correct function prototype) or
> deliberately obtuse.

Under time restrictions, or being extremely uninformed, yes.  These are
precisely the situations that many GCC users are under.

> Now you're the one playing with words. That, or you have a complete
> lack of understanding of extremely common English expressions, which
> you may want to work on as you will otherwise inevitably have large
> problems effectively communicating anything with people on this list.

That my response was so short should have made my point clear, right?
It's a tangent.  I don't claim to speak for anyone other than myself,
and Eli Schwartz implied that I was.

> The "definition of GCC" used here is in a more general sense, i.e. the
> GCC project and the people involved in it that would be considered
> generally representative of it.

But we're debating behavior of the C translator itself, and the
definition of that is clear: the code which comprises the C translator,
cc1, and its frontend, gcc.  What any person thinks, AFAIK, is not
really relevant.

> In fact, so far on this thread I've seen almost nobody on your side of
> the argument, save for a very few extremely loud people repeating the
> same arguments over and over.

>From my perspective, I also see only a few extremely loud people
repeating the same arguments over and over.  But how many times have I
mentioned that?  The number of people in this thread is too small to
conclude anything from.

> So far I've seen only a single minor GCC contributor arguing the
> behavior should be kept as-is - pretty much everyone else agrees the
> behavior should be changed. In fact, I've talked to many people who
> are not currently posting in this thread, who consider that the
> default should be changed, and are watching in consternation as a few
> people appear to be trying to hold back the entire community with
> extremely bad defaults.

In this entire thread of long winded flames, I've not heard a single
reasonable attempt to explain the following points of contention:

  1. Why GCC gets to judge whether or not users' code is correct or not.

  2. How implicit function declarations are different from function
 declarations with no parameter specification, and why it is
 reasonable to make the former an error while allowing the latter.

 By extension, why implicit function declarations are ``always
 wrong'', as some people have been claiming.

 (Aside from, of course, that ``the Standard allows''.
  But the Standard also allows implicit function declarations and
  int.)

  3. How implicit int makes the meaning of a program unclear, in any
 way, with the exception of C2X and auto.  I have not ever seen auto
 explicitly used as a storage class specifier, so from my
 perspective that is not really a problem.

  4. Why people under various time or (mental) energy constraints will
 not simply insert the necessary declarations to pacify GCC, which
 will be as correct as the implicit declaration was.

> In the "C Extensions" section?

The `C Extensions' node is not the only document describing extensions
accompanying the translator.

> By the same line of argumentation, any accepts-invalid is actually not
> a bug and should instead be considered a documentation bug that should
> be fixed by altering the documentation rather than fixing the actual
> bug (given that you appear to consider that making GCC not accept code
> that it previously accepted by default is something that should never
> be done). I hope you understand that's not a reasonable line of
> argumentation.

No, because this is not a bug where GCC accepts invalid code in the
first place.  This is behavior which was explicitly introduced into GCC,
but not documented in a more appropriate location in the manual.

> To be honest, I'd be inclined to consider the current behavior a
> longstanding bug that's been wrongly considered to be a WONTFIX for
> many years, and that we're only now getting around to fixing, if you
> really want to go down this line of argumentation.

Where is the ticket/thread on {Bugzilla,gnu.gcc.bug,gcc-bugs}?  Anyway,
I've never argued anything to this effect.  In fact, I would be more
inclined to consider the decision to not consider this a bug the
decision that explicitly defined it as behavior of the C translator.

> Actually, now that I think about it, what are you actually trying to
> get from 

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Pedro Alves  writes:

> Then write a wrapper script named "cc", and put that in the PATH:
>
>  $ cat cc
>  #!/bin/sh
>
>  exec /my/real/gcc -fwhatever "$@"
>
> Done.

And how many people are going to be forced to do this?

Though this is a good point: I suspect if such an option were actually
added, most sites would simply install such a script as `gcc', and as a
result the stricter behavior would not actually reach anyone.  Making it
pointless, wouldn't you say?

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/12/23 15:19, Po Lu via Gcc wrote:

Jonathan Wakely  writes:


It's not about popularity. If that's your takeaway then you're not
paying attention, whatever you claim about reading everything in the
thread.  It's about helping people write correct code, first time,
without some of the avoidable traps that C presents.

The C ecosystem has a shockingly bad reputation when it comes to
security and "just don't write bugs" is naive and ineffective. Maybe
you're good enough for that to work, but then you should also be able
to cope with a change in defaults.

Right, and how many percent of those came from implicit function
declarations?  Implicit int?  Extern declarations in function scope
being applied at file scope?  Arithmetic between floats being done as
doubles?  Narrow-type promotion to unsigned int?


It's time for some defaults to change so that modern C is preferred,
and "implicit everything, hope the programmer got it right" requires
explicit action, *but it's still possible to do* for the 1970s
nostalgia fans.

It is impossible for implicit int to lead to bugs.
...You're joking, right ? You can't possibly be seriously arguing this, 
you have to be kidding... right ?



If you want to believe that's the start of a slippery slope, that's
your choice. The nostalgia club can always fork gcc if necessary,
that's one of the great things about free software.

I am not part of a nostalgia club, so you might as well stop using this
label.  In courtrooms, the plantiffs may be precluded from using
terminology that can mislead the jury.  This is more or less equivalent.


GCC has always taken backwards compatibility seriously. That doesn't
mean it is the prime directive and can never be violated, but it's
absolutely always considered. In this case, changing the default seems
appropriate to many people, including those who actually maintain gcc
and deal with the consequences of the current defaults.

What consequences?  Really?


Do you have anything new to add other than repeating the same
arguments? We've heard them now, thanks.

Yes, just these quotes from a former GCC maintainer:

   In C, we cannot divide all user code into "right" and "wrong" in this
   kind of simple way, and certainly not based on the ISO standard.  That
   standard is just the decisions of a certain committee (which I was a
   member of) about what cases conforming compilers should commit to
   support.  We must not let ourselves start thinking that C code is
   "wrong", just because it is not conforming ISO C code.

   C programs use many cases that are not conforming, but do work.  This
   will be true for as long as C is used, because changing it would
   require major changes in the C language.

   From time to time, there is a real *need* to make some of these cases
   stop working, for the sake of some benefit that users want.  When this
   happens, we should do it; the user community will accept it, because
   they will see that it is being done for their sake.  Some will
   grumble, but the users who appreciate the benefits will convince them.

   But when there is no *need* to break these cases, when we can keep
   them working fairly easily, we should keep them working.  If we break
   them unnecessarily, we invite the legitimate anger of the users.

and:

   You are arguing for a position that rejects the very idea of making an
   effort to keep old code working.  Your arguments support a general
   conclusion that "If code is not unambiguously valid, it is better to
   break the code than to keep it working."

   This is not just a harsh policy, it is an explicit policy of being
   harsh.  That is, it says, "Be harsh!  Choose the alternative that is
   harsh!"  This is the opposite of the way we should treat our users.

   I understand that your views are not based on sadism or cruelty; you
   think that treating users harshly is better for them.  But your
   motivation, like my motivation, is not the issue anyway.  To adopt a
   policy of harshness towards people--no matter what justification is
   offered for it--is treating them badly.  That is the wrong way to
   treat the users.  We must not make GCC decisions based on a policy of
   harshness.

   I would like future GCC decisions to be based on the policy that
   keeping old code working is a good thing to do, when it is practical
   of course.

   So if any argument leads to the conclusion that one should be harsh to
   the users, please recognize where the argument is taking you, and
   reject it on the grounds that it is a disguised policy of harshness.

   In particular, if it is argued that a policy of kindness has a
   disadvantage, and it turns out that the disadvantage is a consequence
   of the fact that the users have been treated kindly, it is really a
   disguised policy of harshness.

It is sad that this mature attitude no longer seems to be prevalent
among the current maintainership.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Jonathan Wakely  writes:

> Then they should not use implicit int and implicit function
> declarations.

And why is that?  Is GCC really arrogant enough to think that it is the
only C translator in the world?

BTW, standards.info used to say something along the lines of:

  Do not declare functions whose definitions differ between
  systems.  Especially, do not declare any prototypes for them.
  The implicit declaration is likely to be correct.

However, I cannot find it anymore.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Jonathan Wakely  writes:

> It's not about popularity. If that's your takeaway then you're not
> paying attention, whatever you claim about reading everything in the
> thread.  It's about helping people write correct code, first time,
> without some of the avoidable traps that C presents.
>
> The C ecosystem has a shockingly bad reputation when it comes to
> security and "just don't write bugs" is naive and ineffective. Maybe
> you're good enough for that to work, but then you should also be able
> to cope with a change in defaults.

Right, and how many percent of those came from implicit function
declarations?  Implicit int?  Extern declarations in function scope
being applied at file scope?  Arithmetic between floats being done as
doubles?  Narrow-type promotion to unsigned int?

> It's time for some defaults to change so that modern C is preferred,
> and "implicit everything, hope the programmer got it right" requires
> explicit action, *but it's still possible to do* for the 1970s
> nostalgia fans.

It is impossible for implicit int to lead to bugs.

> If you want to believe that's the start of a slippery slope, that's
> your choice. The nostalgia club can always fork gcc if necessary,
> that's one of the great things about free software.

I am not part of a nostalgia club, so you might as well stop using this
label.  In courtrooms, the plantiffs may be precluded from using
terminology that can mislead the jury.  This is more or less equivalent.

> GCC has always taken backwards compatibility seriously. That doesn't
> mean it is the prime directive and can never be violated, but it's
> absolutely always considered. In this case, changing the default seems
> appropriate to many people, including those who actually maintain gcc
> and deal with the consequences of the current defaults.

What consequences?  Really?

> Do you have anything new to add other than repeating the same
> arguments? We've heard them now, thanks.

Yes, just these quotes from a former GCC maintainer:

  In C, we cannot divide all user code into "right" and "wrong" in this
  kind of simple way, and certainly not based on the ISO standard.  That
  standard is just the decisions of a certain committee (which I was a
  member of) about what cases conforming compilers should commit to
  support.  We must not let ourselves start thinking that C code is
  "wrong", just because it is not conforming ISO C code.

  C programs use many cases that are not conforming, but do work.  This
  will be true for as long as C is used, because changing it would
  require major changes in the C language.

  From time to time, there is a real *need* to make some of these cases
  stop working, for the sake of some benefit that users want.  When this
  happens, we should do it; the user community will accept it, because
  they will see that it is being done for their sake.  Some will
  grumble, but the users who appreciate the benefits will convince them.

  But when there is no *need* to break these cases, when we can keep
  them working fairly easily, we should keep them working.  If we break
  them unnecessarily, we invite the legitimate anger of the users.

and:

  You are arguing for a position that rejects the very idea of making an
  effort to keep old code working.  Your arguments support a general
  conclusion that "If code is not unambiguously valid, it is better to
  break the code than to keep it working."

  This is not just a harsh policy, it is an explicit policy of being
  harsh.  That is, it says, "Be harsh!  Choose the alternative that is
  harsh!"  This is the opposite of the way we should treat our users.

  I understand that your views are not based on sadism or cruelty; you
  think that treating users harshly is better for them.  But your
  motivation, like my motivation, is not the issue anyway.  To adopt a
  policy of harshness towards people--no matter what justification is
  offered for it--is treating them badly.  That is the wrong way to
  treat the users.  We must not make GCC decisions based on a policy of
  harshness.

  I would like future GCC decisions to be based on the policy that
  keeping old code working is a good thing to do, when it is practical
  of course.

  So if any argument leads to the conclusion that one should be harsh to
  the users, please recognize where the argument is taking you, and
  reject it on the grounds that it is a disguised policy of harshness.

  In particular, if it is argued that a policy of kindness has a
  disadvantage, and it turns out that the disadvantage is a consequence
  of the fact that the users have been treated kindly, it is really a
  disguised policy of harshness.

It is sad that this mature attitude no longer seems to be prevalent
among the current maintainership.

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/12/23 04:36, Po Lu via Gcc wrote:

Arsen Arsenović  writes:


Indeed they should be - but warning vs. error holds significance.  A
beginner is much less likely to be writing clever code that allegedly
uses these features properly than to be building new code, and simply
having made an error that they do not want and will suffer through
confused.

Most programs already paste a chunk of Autoconf into their configure.ins
which turns on more diagnostics if it looks like the program is being
built by a developer.  i.e. from Emacs:

AC_ARG_ENABLE([gcc-warnings],
   [AS_HELP_STRING([--enable-gcc-warnings@<:@=TYPE@:>@],
   [control generation of GCC warnings.  The TYPE 'yes'
   means to fail if any warnings are issued; 'warn-only'
   means issue warnings without failing (default for
   developer builds); 'no' means disable warnings
   (default for non-developer builds).])],
   [case $enableval in
  yes|no|warn-only) ;;
  *)  AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;;
esac
gl_gcc_warnings=$enableval],
   [# By default, use 'warn-only' if it looks like the invoker of 'configure'
# is a developer as opposed to a builder.  This is most likely true
# if GCC is recent enough and there is a .git directory or file;
# however, if there is also a .tarball-version file it is probably
# just a release imported into Git for patch management.
gl_gcc_warnings=no
if test -d "$srcdir"/.git && test ! -f "$srcdir"/.tarball-version; then
   # Clang typically identifies itself as GCC 4.2 or something similar
   # even if it is recent enough to accept the warnings we enable.
   AS_IF([test "$emacs_cv_clang" = yes],
  [gl_gcc_warnings=warn-only],
  [gl_GCC_VERSION_IFELSE([5], [3], [gl_gcc_warnings=warn-only])])
fi])

So this is really not a problem.


Indeed.  I said facilitates, not treats equally.  I think the veterans
here won't lose much by having to pass -fpermissive, and I think that's
a worthwhile sacrifice to make, to nurture the new without pressuring
the old very much.

Until `-fpermissive' goes the way of `-traditional',
`-fwritable-strings'.


On that note - lets presume a beginners role.  I've just started using
GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
mentions some 'implicit function generation', dunno what that means - if
it mattered much, it'd have been an error.  I wrote a function called
test that prints the int it got in hex, but I called it with 12.3, but
it printed 1.. what the heck?

Have you actually seen anyone make this mistake?
As somebody that spends a lot of time helping beginners, yes, 
constantly. I'd go as far as to say it's an error that seemingly 
everyone has made at least once.



Why that happened is obvious to you and I (if you're on the same CPU as
me), but to a beginner is utter nonsense.

At this point, I can only assume one goes to revisit that warning..  I'd
hope so at least.

I doubt the beginner would know to pass
-Werror=implicit-function-declaration in this case (or even about
Werror...  I just told them what -Wall and to read the warnings, which
was gleefully ignored)

I'd expect a question from the newbie, directed at a web search engine.


Hell, I've seen professors do it, and for a simple reason: they knew how
to write code, not how to use a compiler.  That's a big gap.

The beginner here can't adapt - they don't know what -Wall means, they
just pass it because they were told to do it (if they're lucky!).

If this is really such a bad problem, then how about clarifying the
error message?


At the same time, they lose out on what is, IMO, one of the most useful
pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables
it by default.. we do).  It provides effective bug detection, when the
code compiles right.  It regularly spots bugs that haven't happened yet
for me.

(and same goes for all the other useful analysis the toolchain can do
when it has sufficient information to generate correct code, or more;
some of which can't reasonably be a default)

(on a related note, IMO it's a shame that the toolchain hides so many
possibilities behind 'cult knowledge', depths of many manuals and bad
defaults)

_FORTIFY_SOURCE is not really important enough to be considered here.
It's not even available everywhere.


This sample is subject to selection bias.  My testing targets mostly
more modern codebases that have long fixed these errors (if they have
active maintainers), and exclusively Free Software, so I expect that the
likelyhood that you'll need to run `export CC='gcc -fpermissive'
CXX='g++ -fpermissive'` goes up the more you move towards old or more
corporate codebases, but, for a veteran, this is no cost at all.

Is it that much of a stretch to imagine that a maintainer of a codebase
that has not seen revisions to get it past K practices would
know that they need to pass 

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Fri, May 12, 2023 at 11:33:01AM +0200, Martin Jambor wrote:
> > One fairly big GCC-internal task is to clear up the C test suite so that
> > it passes with the new compiler defaults.  I already have an offer of
> > help for that, so I think we can complete this work in a reasonable time
> > frame.

I'd prefer to keep at least significant portion of those tests as is with
-fpermissive added (plus of course we need new tests that verify the errors
are emitted), so that we have some testsuite coverage for those.

> So, a note to all users of cvise, creduce, delta etc.: Add appropriate
> -Werror flags to your checking scripts so that we don't add more of this :-)

While it is true that for C cvise/creduce/delta often end up with the
implicit ints/implicit function declarations/int-conversions because it
happens to still compile without errors, I and others routinely fix up those
testcases back to valid C provided they still reproduce the reported
problem, so I think it isn't that bad in our testsuite.
But for cvise/creduce/delta reduced testcases with GCC 14 the nice things is
that most of the time these constructs will be gone ;)

Note, using -Werror for all warnings for testsuite reduction often results
in much slower reduction process and larger end result compared to allowing
some warnings but then fixing them up by hand where possible if it still
reproduces.

Jakub

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/12/23 2:01 AM, Po Lu wrote:
> Jason Merrill  writes:
> 
>> You shouldn't have to change any of those, just configure with CC="gcc
>> -fwhatever".
> 
> If it were so simple...
> 
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which are run on the build machine.
> 
> These programs are intended to be as portable as possible (naturally,
> since Autoconf does not configure for the build machine).  As a result,
> they are typically written in the subset of ANSI C that will compile
> with almost any C compiler, which is exactly what will cause problems
> with GCC's proposed new defaults.


This sounds like a "you" problem.

If your Makefiles are totally incapable of respecting the user's choice
of C compiler, you may need to do the same thing that you'd do to
compile it with any alternative compiler: add a directory to your path
containing a wrapper script called "cc" which runs /opt/tinyc/bin/tcc
"$@" or aarch64-linux-gnu-gcc "$@" or whatever.

Although in this case it could just call /usr/bin/gcc -fpermissive "$@"


-- 
Eli Schwartz

Is the GNUC dialect anything that GCC does when given source code containing UB? (Was: More C type errors by default for GCC 14)

[Eli Schwartz via Gcc]

On 5/12/23 1:57 AM, Po Lu wrote:
> Eli Schwartz  writes:
>> It's still no big deal, no matter how much you dramatize the intensity
>> of adding a flag to your Makefiles.
> 
> It's extra work.  Why don't I just write:
> 
>   extern int foo ();
> 
> above each of the new errors?
> That is just about what anyone will do when confronted by these new
> errors.  As a result, you have not ensured that any declarations are
> correct, but instead you have annoyed a lot of people and lulled
> yourself into a false sense of safety.


Instead of adding one flag to their Makefile, which is too much work,
they will add *many* declarations of `extern int foo();` across many
source files in the same project?

Very interesting definition of burdensome work.

You keep saying "just about what anyone will do", but I do not believe
this is what anyone other than you will do.


> This document is the GCC manual, which makes reference (not too clearly,
> however, which should be fixed) to both implicit int and implicit
> function declarations, which are allowed in C99 and later dialects of C.
> 
> These constructs are not bugs.  These constructs explicitly defined by
> GNU C; since a diagnostic is issued, GNU C's implementation also
> conforms to the Standard.


You reading is faulty, and your beliefs about how software work are also
faulty, if you believe that the issuance of a diagnostic is what
constitutes adding new features to the language dialect called "GNU C".

Please start a new thread, titled something like "the documentation is
flawed, which should be fixed, because implicit function declarations
are referenced but not to clearly". Argue there, that implicit function
declarations should be documented on the "C Extensions" page.

Until everyone is on the same page as you about whether these are GNUC
extensions, this conversation will go nowhere.


>> You cannot, and are not permitted, to define "how GCC currently behaves"
>> as "defines what is valid GNU C". No one agrees with your analysis. Most
> ^^
> 
> I'm not a person?


"no one agrees with you" is a common idiom that states that a person (in
this case Po Lu) holds an opinion that rest of the world (all persons
not named Po Lu) do not hold.

Since you cannot agree with yourself -- you are yourself -- I am forced
to believe that you are trolling by accusing me of denying you personhood.


>> importantly, GCC does not agree with your analysis.
> 
> For some definition of GCC, which is apparently you.


No, just the GCC manual.


>> It's a wild, wild, wild claim to begin with. You are arguing that any
>> bug, ANY bug whatsoever, which qualifies for the title "how GCC
>> currently behaves" because if a bug is currently present, then GCC
>> currently behaves in a buggy manner...
>>
>> ... any such bug is, ***because*** GCC currently does it, now part of
>> the documentation on "GNU C", a language dialect with documentation.
>>
>> Can you show me where on
>> https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC
>> documentation states that "C Extensions include anything that GCC
>> currently does, no matter what, no matter how documented or undocumented"?
> 
> I see:
> 
> `-Wno-implicit-int (C and Objective-C only)'
>  This option controls warnings when a declaration does not specify a
>  type.  This warning is enabled by default in C99 and later dialects
>  of C, and also by `-Wall'.
> 
> `-Wno-implicit-function-declaration (C and Objective-C only)'
>  This option controls warnings when a function is used before being
>  declared.  This warning is enabled by default in C99 and later
>  dialects of C, and also by `-Wall'.  The warning is made into an
>  error by `-pedantic-errors'.


Irrelevant, I shall ignore this comment -- it is not listed on the "C
Extensions" page.


>> The concept of a language extension has bulletproof meaning. You cannot
>> get around it, redefine it, pretend that something is when it isn't, or
>> otherwise disagree with this bulletproof meaning.
> 
> The concept of a ``language extension'' is not defined anywhere.
> Instead, there are three kinds of behavior not precisely specified by
> the Standard:


The concept of a language extension is defined by the page that says
"these are the extensions to the language". Please take your mendacious
reading of the C standard and put it back where you got it from.


>   - undefined behavior, the behavior upon use of an erroneous construct
> for which the Standard imposes no requirements whatsoever.
> 
>   - unspecified behavior, where upon the use of a construct for which
> the Standard imposes two or more possible behaviors, and leaves the
> selected behavior unspecified.
> 
>   - implementation-defined behavior, unspecified behavior where each
> implementation documents how the choice is made, and is required to
> document that choice.
> 
> If the translator precisely defines either undefined behavior (in 

Re: More C type errors by default for GCC 14

[David Brown via Gcc]

On 12/05/2023 04:08, Po Lu via Gcc wrote:

Eli Schwartz  writes:





Because that's exactly what is going on here. Features that were valid
C89 code are being used in a GNU99 or GNU11 code file, despite that
***not*** being valid GNU99 or GNU11 code.


How GCC currently behaves defines what is valid GNU C.



What GCC /documents/ defines what is valid GNU C.  (Much of that is, of 
course, imported by reference from the ISO C standards, along with 
target-specific details such as ABI's.)


Anything you write that relies on undocumented behaviour may work by 
luck, not design, and you have no basis for expecting future versions of 
gcc, or any other compiler, to give the same lucky results.


Each version of a compiler is, in fact, a different compiler - that is 
how you should be viewing your tools.  The move between different 
versions of the same compiler is usually much smaller than moving 
between different compiler vendors, but you still look at the release 
notes, change notices, porting information, etc., before changing.  You 
still make considered decisions, and appropriate testing.  You still 
check your build systems and modify flags if needed.  And you do that 
even if you are confident that your code is solid with fully defined 
behaviour and conforming to modern C standards - you might have a bug 
somewhere, and the new compiler version might have a bug.




I am not dictating anything to you or anyone else in this paragraph,
though? All I said was that if one writes a c89 program and tells the
compiler that, then they will not even notice this entire discussion to
begin with.

What, precisely, have I dictated?


That people who are writing GNU C code should be forced to rewrite their
code in ANSI C, in order to make use of GNU C extensions to the 1999
Standard.



You are joking, right?  Surely no one can /still/ be under the 
misapprehension that anyone is proposing GCC stop accepting the old 
code?  All that is changing is the default behaviour, which will mean 
some people might have to use an extra flag or two in their build setup.





However, it does appear that we are still stuck in confusion here,
because you think that GCC is no longer able to compile such code, when
in fact it is able to.


It won't, not by default.



That's pretty much irrelevant.  People don't use gcc without flags.  The 
only thing that will change is which flags you need to use.


If you are not in a position to change the source code, and not in a 
position to change the build flags, then you are not in a position to 
change the compiler version.  (That's fine, of course - in my line of 
work, I almost never change compiler version for existing projects.  I 
have old code where the makefile specifies gcc 2.95.)


David

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/12/23 08:25, Eli Zaretskii via Gcc wrote:

Date: Thu, 11 May 2023 18:43:32 -0400
Cc: luang...@yahoo.com, gcc@gcc.gnu.org
From: Eli Schwartz 

On 5/11/23 2:24 AM, Eli Zaretskii wrote:


Back to the subject: the guarantees I would personally like to have is
that the current GCC development team sees backward compatibility as
an important goal, and will try not to break old programs without very
good technical reasons.  At least in Emacs development, that is the
consideration that is very high on our priority list when making
development decisions.  It would be nice if GCC (and any other GNU
project, for that matter) would do the same, because being able to
upgrade important tools and packages without fear is something users
value very much.  Take it from someone who uses GCC on various
platforms since version 1.40.

This discussion thread is about having very good technical reasons -- as
explained multiple times, including instances where you agreed that the
technical reasons were good.

They are not technical, no.  Leaving the current behavior does not
technically hamper GCC and its users in any way -- GCC can still
compile the same programs, including those with modern std= values, as
it did before, and no false warnings or errors are caused when
compiling programs written in valid standard C.


The current behavior hampers GCC's users in very significant ways: it 
encourages people who are new to the language to write completely broken 
code in ways that should have been at least slightly harder to 
accomplish since a quarter of a century ago.


Arguing that GCC should compile any "valid standard C" seems like an 
obviously flawed premise to me given that unless you're going the 
strictly conforming route, a "program" such as:


]iN$<\J3"`q
Tf;9ge0k\hm[
!Zsr>MtiV B@
~x?M\A):.s0^W
2$((g]'Vx:jZ
D'?n/X_li|;E
aLA%WQmzNq-(QG'
r"rSV3|]k_BU?R
p:hPWg_(]Y(
And,3xD{iR5B

may be considered by any implementation as a valid standard C program, 
since it does not contain an #error directive.


Such examples may seem like hyperbole to you, but to a beginner, the 
constructs that you wish to leave usable in GCC unaltered may well be 
just about as confusing as you might find any interpretation of the 
valid standard C program presented above to be.


You may not be aware of this, but the current behavior leads to endless 
instances of beginners accidentally using utterly broken constructs and 
then coming to C forums/channels/etc. asking for help, only for people 
like me to discover that such code is still compiled by GCC now without 
anymore than a warning being given to the user (which they extremely 
commonly ignore). Having been on such forums for years, I'd estimate 
that this actually represents a genuinely significant proportion of the 
problems I help diagnose - about 10% or so (though I have of course not 
made a detailed study of every problem I've ever helped solve, but I'm 
relatively confident 10% is not too far from the real proportion). To be 
honest, it's such a common problem that I'm genuinely surprised it 
hasn't spawned off jokes in the same way things like 
T_PAAMAYIM_NEKUDOTAYIM in PHP have (I guess "implicit function 
declaration" has less of a ring to it than T_PAAMAYIM_NEKUDOTAYIM)




The reasons are basically PR: better reputation for GCC etc.  Maybe
even fashion: Clang does that, so how come we don't?


Furthermore, even despite those technical reasons, GCC is *still*
committed to not breaking those old programs anyway. GCC merely wants to
make those old programs have to be compiled in an "old-programs" mode.

Can you explain to me how you think this goal conflicts with your goal?

I already did, in previous messages, where I described what we all are
familiar with: the plight of a maintainer of a large software system
whose build suddenly breaks, and the difficulty in understanding which
part of the system's upgrade caused that.  I'd rather not repeat that:
there are already too many repetitions here that make the discussion
harder to follow.

Re: More C type errors by default for GCC 14

[Gabriel Ravier via Gcc]

On 5/12/23 07:57, Po Lu via Gcc wrote:

Eli Schwartz  writes:


There are ***not*** thousands of Makefiles that have this issue. But if
there were, then Makefiles are very easy to update, and only have to be
updated once per project, not thousands of times. So this is fine. You
may have to update your Makefile, but that is no big deal.

It's still no big deal, no matter how much you dramatize the intensity
of adding a flag to your Makefiles.

It's extra work.  Why don't I just write:

   extern int foo ();

above each of the new errors?
That is just about what anyone will do when confronted by these new
errors.  As a result, you have not ensured that any declarations are
correct, but instead you have annoyed a lot of people and lulled
yourself into a false sense of safety.


It's "extra work" to add 10 characters to a Makefile, but normal to add 
random faulty declarations everywhere ? I could only imagine someone 
doing this if they're being either extremely uninformed, extremely 
restricted (e.g. no change to any configuration files, no pragmas to 
disable the errors and not even having 10 seconds to look up the correct 
function prototype) or deliberately obtuse.





So you concede that GCC is not telling you, only trying and failing to
tell you?

I concede that you're playing with words.


Great, so what's the problem? If GCC can't actually enforce it, and even
goes out of its way to offer you options to ignore what it's telling you
to do, then maybe...

... it's not telling you what to do with your code, only suggesting what
to do?

So ignore the suggestion.

Which is made annoying, especially when there is absolutely NO guarantee
being made that the new option will stay.


I'm not sure what this semantics game here is trying to say. Is it
ethically and morally wrong for GCC to try to tell you what to do with
your code? Is it undignifying to have a mere machine go and lecture you,
a real human being with a consciousness and free will, what to do?

Because if that's what this is about then I think you are taking this
inanimate object way too personally.

If not, then I am simply entirely unsure what your objection is to being
"told".



Because that's exactly what is going on here. Features that were valid
C89 code are being used in a GNU99 or GNU11 code file, despite that
***not*** being valid GNU99 or GNU11 code.

How GCC currently behaves defines what is valid GNU C.


No. Absolutely positively 100% no under any circumstances whatsoever no.

This has been explained multiple times by the GCC developers. e.g.
search for references to accepts-invalid.

"""
They are bugs where compiler accepts something that isn't valid in
the selected language nor considered valid extension.
So, after the fix we reject something that has been accepted before.

In the last few years (checked what was fixed in 10/11/12/13 releases so
far), we've fixed 12 such bugs explicitly marked that way:
"""

The Standard states that each conforming implementation must be
accompanied by a document which documents each and every extension.

This document is the GCC manual, which makes reference (not too clearly,
however, which should be fixed) to both implicit int and implicit
function declarations, which are allowed in C99 and later dialects of C.

These constructs are not bugs.  These constructs explicitly defined by
GNU C; since a diagnostic is issued, GNU C's implementation also
conforms to the Standard.


You cannot, and are not permitted, to define "how GCC currently behaves"
as "defines what is valid GNU C". No one agrees with your analysis. Most

 ^^

I'm not a person?
Now you're the one playing with words. That, or you have a complete lack 
of understanding of extremely common English expressions, which you may 
want to work on as you will otherwise inevitably have large problems 
effectively communicating anything with people on this list.



importantly, GCC does not agree with your analysis.

For some definition of GCC, which is apparently you.
The "definition of GCC" used here is in a more general sense, i.e. the 
GCC project and the people involved in it that would be considered 
generally representative of it. In fact, so far on this thread I've seen 
almost nobody on your side of the argument, save for a very few 
extremely loud people repeating the same arguments over and over. So far 
I've seen only a single minor GCC contributor arguing the behavior 
should be kept as-is - pretty much everyone else agrees the behavior 
should be changed. In fact, I've talked to many people who are not 
currently posting in this thread, who consider that the default should 
be changed, and are watching in consternation as a few people appear to 
be trying to hold back the entire community with extremely bad defaults.



It's a wild, wild, wild claim to begin with. You are arguing that any
bug, ANY bug whatsoever, which qualifies for the title "how GCC
currently behaves" because if a bug is 

Re: More C type errors by default for GCC 14

[Pedro Alves]

On 2023-05-12 7:01 a.m., Po Lu via Gcc wrote:
> Jason Merrill  writes:
> 
>> You shouldn't have to change any of those, just configure with CC="gcc
>> -fwhatever".
> 
> If it were so simple...
> 
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which are run on the build machine.

Then write a wrapper script named "cc", and put that in the PATH:

 $ cat cc
 #!/bin/sh

 exec /my/real/gcc -fwhatever "$@"

Done.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Fri, 12 May 2023 10:15:45 +0200
> From: Jakub Jelinek 
> Cc: Arsen Arsenović , luang...@yahoo.com,
> jwakely@gmail.com, gcc@gcc.gnu.org
> 
> On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote:
> > 
> > Let's keep in mind that veterans are much more likely to have to deal
> > with very large programs than newbies, and so dealing with breakage
> > for them is much harder than doing that in a toy program.  Thus, the
> > proposal does "pressure the old very much".
> 
> Pressure for something they should have done decades ago if the code was
> really maintained.

Why not assume that at least some of them didn't because they had good
reasons?

> Anyway, I don't understand why these 3 (implicit fn declarations,
> implicit ints and int-conversions) are so different from anything that
> one needs to change in codebases every year as documented in
> gcc.gnu.org/gcc-NN/porting_to.html .  It is true that for C++ there are
> more such changes than for C, but say GCC 12 no longer accepts
> computed gotos with non-pointer types, GCC 10 changed default from
> -fcommon to -fno-common for C which also affects dusty codebases
> significantly, GCC 9 changed the lifetime of block scope compound literals
> (again, affected various old codebases), GCC 5 broke bad user expectations
> regarding preprocessor behavior by adding extra line markers to represent
> whether certain tokens come from system headers or not, etc.
> And of course compiler optimizations added every year can turn previously
> "working" code with undefined behaviors in it into code not working as user
> expected.  E.g. compared to the above 3 that are easily fixed, it is obvious
> what the problem is, tracking undefined behavior in code even when one
> has sanitizers etc. is much more time consuming.

The difference, IMO, is that in all the cases you describe the changes
were done because they were necessary for GCC to support some new
feature, or fix a bug.  By contrast, in this case there's no new
features that require to fail to compile the code in question.

> Can we stop this thread.  I'm afraid everything has been said multiple
> times, it is up to the GCC Steering Committee to decide this if there is
> disagreement on it among GCC developers, but my current understanding is
> that that is not the case here and that the active GCC developers agree on
> it.

Fine, I will stop posting at this point.  Thanks for listening.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Jonathan Wakely 
> Date: Fri, 12 May 2023 08:28:00 +0100
> Cc: Eli Schwartz , Po Lu , 
>   "gcc@gcc.gnu.org" 
> 
>  It is on topic because there doesn't seem to be anything in the
>  arguments brought up for this current proposal that couldn't be
>  brought up in favor of removing -fpermissive.  There are no guiding
>  principles being uttered which allow the current proposal, but will
>  disallow the removal of -fpermissive.  
> 
> "Let's change a default and add an option to get the old default" is really 
> not the disaster you're making
> it out to be. You're becoming a laughing stock at this point.

I'm sad to hear that you consider this laughable.  I hope the
development team as a whole and the steering committee will consider
that more seriously.

>  The same "let's be more popular
>  and forthcoming to newbies, and more like Clang" PR-style stuff can
>  justify both.
> 
> It's not about popularity. If that's your takeaway then you're not paying 
> attention, whatever you claim
> about reading everything in the thread. It's about helping people write 
> correct code, first time, without
> some of the avoidable traps that C presents.

GCC already helps those people who want to be helped.  This was
pointed out several times.

> The C ecosystem has a shockingly bad reputation when it comes to security and 
> "just don't write
> bugs" is naive and ineffective. Maybe you're good enough for that to work, 
> but then you should also be
> able to cope with a change in defaults.
> 
> It's time for some defaults to change so that modern C is preferred, and 
> "implicit everything, hope the
> programmer got it right" requires explicit action, *but it's still possible 
> to do* for the 1970s nostalgia
> fans.

That's just a bunch of slogans.  Decisions about backward-incompatible
changes should do better than heed slogans.

>  > We might as well assume that the GCC developers are honest and truthful
>  > people, otherwise it is *definitely* a waste of time asking them about
>  > this change in the first place.
> 
>  This is not about honesty.  No one is questioning the honesty of GCC
>  developers.  What is being questioned are the overriding principles
>  that should be applied when backward-incompatible changes are
>  proposed.  Are there such principles in GCC development, and if there
>  are, where are they documented?  Or are such discussions just some
>  ad-hoc disputes, and the results are determined by which party is at
>  that time more vocal?
> 
> GCC has always taken backwards compatibility seriously. That doesn't mean it 
> is the prime directive
> and can never be violated, but it's absolutely always considered.

Considered and dismissed, it seems, at least judging by your
responses.

As for when it can be violated, I already explained my opinions.
TL;DR: there are valid cases, but not in this case.

> In this case, changing the default
> seems appropriate to many people, including those who actually maintain gcc 
> and deal with the
> consequences of the current defaults.

These decisions should not be based on majority votes.  Breaking even
one person's code is much worse than helping many others realize more
clearly their code needs to be fixed.

> Do you have anything new to add other than repeating the same arguments? 
> We've heard them now,
> thanks.

Oh, please drop the attitude.  You are not making your arguments more
convincing by being hostile and ad-hominem.  We are supposed to have
the same goals.

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Fri, 12 May 2023 at 09:46, Christian Groessler  wrote:
>
> On 5/12/23 09:53, Eli Zaretskii via Gcc wrote:
> >
> >> With all that to consider, is it *really* a significant cost to add
> >> -fpermissive?
> >
> > See above (and my earlier message): the significant cost is to
> > discover the root cause of the problem, and that -fpermissive is the
> > solution.  The rest might be relatively easier, at least in some
> > projects.
>
>
> -fpermissive seems to be posted as the standard solution in this thread,
>
> I don't know what constructs it allows, but it might enable things the
> user doesn't want besides silencing this new change.

Currently that flag doesn't exist for C at all, so it will be added
with exactly the meaning of reverting the new change. Nothing more,
nothing less.

But if you don't want all of that (maybe you want to use implicit
function decls but not implicit int) then you will still have
individual flags to control those, so you don't have to use
-fpermissive.

You would be able to use -Wno-error=implicit-function-declaration to
just allow those, but keep giving errors for implicit int.

>
> So it seems to be more effort than to "just add -fpermissive" to get the
> code to compile again.

That's just speculation based on misunderstanding of the proposal. A
reasonable misunderstanding, but you'll be able to just disable the
errors that you don't want.


> Think about big code bases where many developers are working on in
> different areas.

Don't assume the people proposing this haven't thought about that, in
detail, for several years.

Re: More C type errors by default for GCC 14

[Martin Jambor]

Hi,

On Tue, May 09 2023, Florian Weimer via Gcc wrote:
> TL;DR: This message is about turning implicit-int,
> implicit-function-declaration, and possibly int-conversion into errors
> for GCC 14.
>

FWIW, I personally support the proposal.

Regarding the huge discussion that ensued, I would just like to point
out that the proposal is put forward by people from organizations which
are huge users of GCC and know perfectly well the transition will be
painful and yet are prepared face it, for reasons that were nicely
explained by Florian.  AFAIK, we at SUSE share the sentiment.

[...]

> Regarding mechanics of the necessary opt out facility, Clang used
> -Werror=… by default, but that seems a bit hackish to me.  Presently, we
> cannot use -std=gnu89 etc. to opt out because there are packages which
> require both C89-only language features and C99-style inlining, which is
> currently not a combination supported by GCC (but maybe that could be
> changed).  Some build systems do not treat CFLAGS and CXXFLAGS as fully
> separate, and a flag approach that works for C and C++ without
> introducing any new warnings would be most convenient.  So maybe we
> could use -fpermissive for C as well.

I like -fpermissive, but the -Wno-error-... options are actually quite
intuitive, perhaps we could do both?  But I do not have a strong
preference.

> One fairly big GCC-internal task is to clear up the C test suite so that
> it passes with the new compiler defaults.  I already have an offer of
> help for that, so I think we can complete this work in a reasonable time
> frame.
>

So, a note to all users of cvise, creduce, delta etc.: Add appropriate
-Werror flags to your checking scripts so that we don't add more of this :-)

Thanks for putting effort into this.

Martin

Re: More C type errors by default for GCC 14

[Thomas Koenig via Gcc]

On 12.05.23 09:53, Eli Zaretskii via Gcc wrote:

I described in an earlier message how this breakage looks in real
life, and why it causes a lot of frustration.  The main problem is
discovering that things broke because GCC defaults, and then
discovering how to pacify GCC with the least effort.


Gcc is quite helpful these days:

$ gcc -c example.c
example.c:1:1: warning: data definition has no type or storage class
1 | a();
  | ^
example.c:1:1: warning: type defaults to 'int' in declaration of 'a' 
[-Wimplicit-int]

$ gcc -Werror -c example.c
example.c:1:1: error: data definition has no type or storage class [-Werror]
1 | a();
  | ^
example.c:1:1: error: type defaults to 'int' in declaration of 'a' 
[-Werror=implicit-int]


(sorry, cannot show the nice coloring).

It tells you right in the error message which option caused the
or warning in question.  This is not hard.

Is your opinion that reading error messages (and making the mental
leap of adding the negative, of course) is too much to expect?

Best regards

Thomas

Re: More C type errors by default for GCC 14

[Christian Groessler]

On 5/12/23 09:53, Eli Zaretskii via Gcc wrote:



With all that to consider, is it *really* a significant cost to add
-fpermissive?


See above (and my earlier message): the significant cost is to
discover the root cause of the problem, and that -fpermissive is the
solution.  The rest might be relatively easier, at least in some
projects.



-fpermissive seems to be posted as the standard solution in this thread,

I don't know what constructs it allows, but it might enable things the 
user doesn't want besides silencing this new change.


So it seems to be more effort than to "just add -fpermissive" to get the 
code to compile again.


Think about big code bases where many developers are working on in 
different areas.


regards,
chris

Re: More C type errors by default for GCC 14

[Jakub Jelinek via Gcc]

On Fri, May 12, 2023 at 10:53:28AM +0300, Eli Zaretskii via Gcc wrote:
> > From: Arsen Arsenović 
> > Cc: luang...@yahoo.com, jwakely@gmail.com, gcc@gcc.gnu.org
> > Date: Thu, 11 May 2023 21:25:53 +0200
> > 
> > >> This seems like a good route to me - it facilitates both veterans
> > >> maintaining code and beginners just learning how to write C.
> > >
> > > No, it prefers beginners (which already have the warnings, unless they
> > > deliberately turn them off) to veterans who know what they are doing,
> > > and can live with those warnings.
> > 
> > Indeed.  I said facilitates, not treats equally.  I think the veterans
> > here won't lose much by having to pass -fpermissive, and I think that's
> > a worthwhile sacrifice to make, to nurture the new without pressuring
> > the old very much.
> 
> Let's keep in mind that veterans are much more likely to have to deal
> with very large programs than newbies, and so dealing with breakage
> for them is much harder than doing that in a toy program.  Thus, the
> proposal does "pressure the old very much".

Pressure for something they should have done decades ago if the code was
really maintained.
Anyway, I don't understand why these 3 (implicit fn declarations,
implicit ints and int-conversions) are so different from anything that
one needs to change in codebases every year as documented in
gcc.gnu.org/gcc-NN/porting_to.html .  It is true that for C++ there are
more such changes than for C, but say GCC 12 no longer accepts
computed gotos with non-pointer types, GCC 10 changed default from
-fcommon to -fno-common for C which also affects dusty codebases
significantly, GCC 9 changed the lifetime of block scope compound literals
(again, affected various old codebases), GCC 5 broke bad user expectations
regarding preprocessor behavior by adding extra line markers to represent
whether certain tokens come from system headers or not, etc.
And of course compiler optimizations added every year can turn previously
"working" code with undefined behaviors in it into code not working as user
expected.  E.g. compared to the above 3 that are easily fixed, it is obvious
what the problem is, tracking undefined behavior in code even when one
has sanitizers etc. is much more time consuming.

Can we stop this thread.  I'm afraid everything has been said multiple
times, it is up to the GCC Steering Committee to decide this if there is
disagreement on it among GCC developers, but my current understanding is
that that is not the case here and that the active GCC developers agree on
it.

Jakub

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Arsen Arsenović 
> Cc: luang...@yahoo.com, jwakely@gmail.com, gcc@gcc.gnu.org
> Date: Thu, 11 May 2023 21:25:53 +0200
> 
> >> This seems like a good route to me - it facilitates both veterans
> >> maintaining code and beginners just learning how to write C.
> >
> > No, it prefers beginners (which already have the warnings, unless they
> > deliberately turn them off) to veterans who know what they are doing,
> > and can live with those warnings.
> 
> Indeed.  I said facilitates, not treats equally.  I think the veterans
> here won't lose much by having to pass -fpermissive, and I think that's
> a worthwhile sacrifice to make, to nurture the new without pressuring
> the old very much.

Let's keep in mind that veterans are much more likely to have to deal
with very large programs than newbies, and so dealing with breakage
for them is much harder than doing that in a toy program.  Thus, the
proposal does "pressure the old very much".

> > The right balance is exactly what we have now: emitting warnings
> > without breaking builds.
> 
> I disagree - I think breaking builds here (remember, it takes 13 bytes
> to fix them) is a much lower weight than the other case being shot in
> the foot for an easily detectable and treatable error being made easily
> missable instead, so I reckon the scale is tipped heavily towards the
> veterans.

I described in an earlier message how this breakage looks in real
life, and why it causes a lot of frustration.  The main problem is
discovering that things broke because GCC defaults, and then
discovering how to pacify GCC with the least effort.  You are talking
only about what follows these two discovery processes, and that misses
the main disadvantage of this proposal (an in fact almost any breaking
proposal).

> On that note - lets presume a beginners role.  I've just started using
> GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
> mentions some 'implicit function generation', dunno what that means - if
> it mattered much, it'd have been an error.  I wrote a function called
> test that prints the int it got in hex, but I called it with 12.3, but
> it printed 1.. what the heck?
> 
> Why that happened is obvious to you and I (if you're on the same CPU as
> me), but to a beginner is utter nonsense.
> 
> At this point, I can only assume one goes to revisit that warning..  I'd
> hope so at least.

That's perfectly okay: the beginner made a mistake of ignoring a
warning, and now he or she will need to pay for that mistake.

But why should someone else pay, and pay dearly, for the mistakes of
such newbies?  That is simply unfair.  The payment should be on the
one who made the mistake.

> I doubt the beginner would know to pass
> -Werror=implicit-function-declaration in this case (or even about
> Werror...  I just told them what -Wall and to read the warnings, which
> was gleefully ignored)

They don't need to.  They just need to fix their bad code, that's all.

> Is it that much of a stretch to imagine that a maintainer of a codebase
> that has not seen revisions to get it past K practices would
> know that they need to pass -std=c89 (or a variant of such), or even
> -fpermissive - assuming that they could even spare to use GCC 14 as
> opposed to 2.95?

If the program built okay till now, they might not know.

> As an anecdote, just recently I had to fix some code written for i686
> CPUs, presumably for GCC 4.something or less, because the GCC I insist
> on using (which is 13 and has been since 13.0 went into feature-freeze)
> has started using more than the GPRs on that machine (which lead to hard
> to debug crashes because said codebase does not enable the requisite CPU
> extensions, or handle the requisite registers properly).  I think this
> fits within the definition of 'worked yesterday, broke today'.

But it broke for a valid technical reasons: GCC was improved by
supporting more registers, and thus it now emits better code.  This
kind of reason is perfectly legitimate for breaking some old and
borderline-invalid programs, especially if GCC was emitting warnings
for those programs in past releases.

But the change discussed here is not like that.

> With all that to consider, is it *really* a significant cost to add
> -fpermissive?

See above (and my earlier message): the significant cost is to
discover the root cause of the problem, and that -fpermissive is the
solution.  The rest might be relatively easier, at least in some
projects.

> I expect no change in behavior from those that maintain these old
> codebases, they know what they're doing, and they have bigger fish to
> fry - however, I expect that this change will result in:
> 
> - A better reputation for GCC and the GCC project (by showing that we do
>   care for code correctness),
> - More new code being less error prone (by merit of simple errors being
>   detected more often),
> - Less 'cult knowledge' in the garden path,
> - More responsible beginners, and
> - Fewer people being able to 

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Fri, 12 May 2023, 07:56 Eli Zaretskii via Gcc,  wrote:

> > Date: Thu, 11 May 2023 23:07:55 -0400
> > Cc: gcc@gcc.gnu.org
> > From: Eli Schwartz via Gcc 
> >
> > > Being sceptical about the future is perfectly reasonable.
> >
> > My opinion on this is (still) that if your argument is that you don't
> > want -fpermissive or -std=c89 to be removed, you are more than welcome
> > to be skeptical about that (either one or both), but I don't see why
> > that is on topic for the question of whether things should be moved to
> > flags such as those while they do exist.
>
> It is on topic because there doesn't seem to be anything in the
> arguments brought up for this current proposal that couldn't be
> brought up in favor of removing -fpermissive.  There are no guiding
> principles being uttered which allow the current proposal, but will
> disallow the removal of -fpermissive.



"Let's change a default and add an option to get the old default" is really
not the disaster you're making it out to be. You're becoming a laughing
stock at this point.


The same "let's be more popular
> and forthcoming to newbies, and more like Clang" PR-style stuff can
> justify both.
>


It's not about popularity. If that's your takeaway then you're not paying
attention, whatever you claim about reading everything in the thread. It's
about helping people write correct code, first time, without some of the
avoidable traps that C presents.

The C ecosystem has a shockingly bad reputation when it comes to security
and "just don't write bugs" is naive and ineffective. Maybe you're good
enough for that to work, but then you should also be able to cope with a
change in defaults.

It's time for some defaults to change so that modern C is preferred, and
"implicit everything, hope the programmer got it right" requires explicit
action, *but it's still possible to do* for the 1970s nostalgia fans.

If you want to believe that's the start of a slippery slope, that's your
choice. The nostalgia club can always fork gcc if necessary, that's one of
the great things about free software.


> > We might as well assume that the GCC developers are honest and truthful
> > people, otherwise it is *definitely* a waste of time asking them about
> > this change in the first place.
>
> This is not about honesty.  No one is questioning the honesty of GCC
> developers.  What is being questioned are the overriding principles
> that should be applied when backward-incompatible changes are
> proposed.  Are there such principles in GCC development, and if there
> are, where are they documented?  Or are such discussions just some
> ad-hoc disputes, and the results are determined by which party is at
> that time more vocal?
>

GCC has always taken backwards compatibility seriously. That doesn't mean
it is the prime directive and can never be violated, but it's absolutely
always considered. In this case, changing the default seems appropriate to
many people, including those who actually maintain gcc and deal with the
consequences of the current defaults.

Do you have anything new to add other than repeating the same arguments?
We've heard them now, thanks.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Thu, 11 May 2023 23:07:55 -0400
> Cc: gcc@gcc.gnu.org
> From: Eli Schwartz via Gcc 
> 
> > Being sceptical about the future is perfectly reasonable.
> 
> My opinion on this is (still) that if your argument is that you don't
> want -fpermissive or -std=c89 to be removed, you are more than welcome
> to be skeptical about that (either one or both), but I don't see why
> that is on topic for the question of whether things should be moved to
> flags such as those while they do exist.

It is on topic because there doesn't seem to be anything in the
arguments brought up for this current proposal that couldn't be
brought up in favor of removing -fpermissive.  There are no guiding
principles being uttered which allow the current proposal, but will
disallow the removal of -fpermissive.  The same "let's be more popular
and forthcoming to newbies, and more like Clang" PR-style stuff can
justify both.

> We might as well assume that the GCC developers are honest and truthful
> people, otherwise it is *definitely* a waste of time asking them about
> this change in the first place.

This is not about honesty.  No one is questioning the honesty of GCC
developers.  What is being questioned are the overriding principles
that should be applied when backward-incompatible changes are
proposed.  Are there such principles in GCC development, and if there
are, where are they documented?  Or are such discussions just some
ad-hoc disputes, and the results are determined by which party is at
that time more vocal?

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> From: Jason Merrill 
> Date: Thu, 11 May 2023 22:55:07 -0400
> Cc: Eli Schwartz , Eli Zaretskii , 
> gcc@gcc.gnu.org
> 
> > Because now people will have to go through dozens and dozens of
> > Makefiles, configure.in, *.m4
> 
> You shouldn't have to change any of those, just configure with CC="gcc
> -fwhatever".

That doesn't always work.  Whether it works or not depends on how the
Makefile's are written, whether libtool is or isn't being used, etc.

So yes, it will work in some, perhaps many, cases, but not in all of
them.

Moreover, the main problem with such a change is discovering that the
build broke because of different GCC defaults, and that adding
"-fpermissive" is all that's needed to pacify GCC.  I already tried to
explain why this is nowhere as simple in real life as some people here
seem to assume.  The aggravation and frustration caused by that
process of discovery is the main downside of this proposal, and I hope
it will be considered very seriously when making the decision.

Re: More C type errors by default for GCC 14

[Jonathan Wakely via Gcc]

On Fri, 12 May 2023, 07:02 Po Lu via Gcc,  wrote:

> Jason Merrill  writes:
>
> > You shouldn't have to change any of those, just configure with CC="gcc
> > -fwhatever".
>
> If it were so simple...
>
> Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
> `cc', to build programs which are run on the build machine.
>
> These programs are intended to be as portable as possible (naturally,
> since Autoconf does not configure for the build machine).  As a result,
> they are typically written in the subset of ANSI C that will compile
> with almost any C compiler, which is exactly what will cause problems
> with GCC's proposed new defaults.
>

Then they should not use implicit int and implicit function declarations.

You've made your opinion clear. It has been noted.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Thu, 11 May 2023 18:43:32 -0400
> Cc: luang...@yahoo.com, gcc@gcc.gnu.org
> From: Eli Schwartz 
> 
> On 5/11/23 2:24 AM, Eli Zaretskii wrote:
> 
> > Back to the subject: the guarantees I would personally like to have is
> > that the current GCC development team sees backward compatibility as
> > an important goal, and will try not to break old programs without very
> > good technical reasons.  At least in Emacs development, that is the
> > consideration that is very high on our priority list when making
> > development decisions.  It would be nice if GCC (and any other GNU
> > project, for that matter) would do the same, because being able to
> > upgrade important tools and packages without fear is something users
> > value very much.  Take it from someone who uses GCC on various
> > platforms since version 1.40.
> 
> This discussion thread is about having very good technical reasons -- as
> explained multiple times, including instances where you agreed that the
> technical reasons were good.

They are not technical, no.  Leaving the current behavior does not
technically hamper GCC and its users in any way -- GCC can still
compile the same programs, including those with modern std= values, as
it did before, and no false warnings or errors are caused when
compiling programs written in valid standard C.

The reasons are basically PR: better reputation for GCC etc.  Maybe
even fashion: Clang does that, so how come we don't?

> Furthermore, even despite those technical reasons, GCC is *still*
> committed to not breaking those old programs anyway. GCC merely wants to
> make those old programs have to be compiled in an "old-programs" mode.
> 
> Can you explain to me how you think this goal conflicts with your goal?

I already did, in previous messages, where I described what we all are
familiar with: the plight of a maintainer of a large software system
whose build suddenly breaks, and the difficulty in understanding which
part of the system's upgrade caused that.  I'd rather not repeat that:
there are already too many repetitions here that make the discussion
harder to follow.

Re: More C type errors by default for GCC 14

[Eli Zaretskii via Gcc]

> Date: Thu, 11 May 2023 18:30:20 -0400
> Cc: luang...@yahoo.com, gcc@gcc.gnu.org
> From: Eli Schwartz 
> 
> On 5/11/23 2:12 AM, Eli Zaretskii wrote:
> > 
> > He is telling you that removing support for these old features, you
> > draw users away from GCC and towards proprietary compilers.
> > 
> > One of the arguments in this thread _for_ dropping that support was
> > that by not rejecting those old programs, GCC draws some users away
> > from GCC.  He is telling you that this change will, perhaps, draw some
> > people to GCC, but will draw others away from GCC.  The difference is
> > that the former group will start using Clang, which is still free
> > software (at least some of its versions), whereas the latter group has
> > nowhere to go but to proprietary compilers.  So the FOSS community
> > will have suffered a net loss.  Something to consider, I think.
> 
> But I do not understand the comparison to -traditional. Which was
> already removed, and already resulted in, apparently, at least one group
> being so adamant on not-C that it switched to a proprietary compiler.
> Okay, understood. But at this point that group is no longer users of
> GCC... right?
> 
> So what is the moral of this story?

See above: that repeating the story of -traditional could result in
net loss for the FOSS movement.

> To avoid repeating the story of -traditional, and instead make sure
> that users of -std=c89 always have a flag they can use to indicate
> they are writing old c89 code?

No, the moral is not to introduce breaking behavior without very good
technical reasons.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Jason Merrill  writes:

> You shouldn't have to change any of those, just configure with CC="gcc
> -fwhatever".

If it were so simple...

Many Makefiles come with a habit of using not CC_FOR_BUILD, but just
`cc', to build programs which are run on the build machine.

These programs are intended to be as portable as possible (naturally,
since Autoconf does not configure for the build machine).  As a result,
they are typically written in the subset of ANSI C that will compile
with almost any C compiler, which is exactly what will cause problems
with GCC's proposed new defaults.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> There are ***not*** thousands of Makefiles that have this issue. But if
> there were, then Makefiles are very easy to update, and only have to be
> updated once per project, not thousands of times. So this is fine. You
> may have to update your Makefile, but that is no big deal.
>
> It's still no big deal, no matter how much you dramatize the intensity
> of adding a flag to your Makefiles.

It's extra work.  Why don't I just write:

  extern int foo ();

above each of the new errors?
That is just about what anyone will do when confronted by these new
errors.  As a result, you have not ensured that any declarations are
correct, but instead you have annoyed a lot of people and lulled
yourself into a false sense of safety.

> So you concede that GCC is not telling you, only trying and failing to
> tell you?

I concede that you're playing with words.

> Great, so what's the problem? If GCC can't actually enforce it, and even
> goes out of its way to offer you options to ignore what it's telling you
> to do, then maybe...
>
> ... it's not telling you what to do with your code, only suggesting what
> to do?
>
> So ignore the suggestion.

Which is made annoying, especially when there is absolutely NO guarantee
being made that the new option will stay.

> I'm not sure what this semantics game here is trying to say. Is it
> ethically and morally wrong for GCC to try to tell you what to do with
> your code? Is it undignifying to have a mere machine go and lecture you,
> a real human being with a consciousness and free will, what to do?
>
> Because if that's what this is about then I think you are taking this
> inanimate object way too personally.
>
> If not, then I am simply entirely unsure what your objection is to being
> "told".
>
>
>>> Because that's exactly what is going on here. Features that were valid
>>> C89 code are being used in a GNU99 or GNU11 code file, despite that
>>> ***not*** being valid GNU99 or GNU11 code.
>> 
>> How GCC currently behaves defines what is valid GNU C.
>
>
> No. Absolutely positively 100% no under any circumstances whatsoever no.
>
> This has been explained multiple times by the GCC developers. e.g.
> search for references to accepts-invalid.
>
> """
> They are bugs where compiler accepts something that isn't valid in
> the selected language nor considered valid extension.
> So, after the fix we reject something that has been accepted before.
>
> In the last few years (checked what was fixed in 10/11/12/13 releases so
> far), we've fixed 12 such bugs explicitly marked that way:
> """

The Standard states that each conforming implementation must be
accompanied by a document which documents each and every extension.

This document is the GCC manual, which makes reference (not too clearly,
however, which should be fixed) to both implicit int and implicit
function declarations, which are allowed in C99 and later dialects of C.

These constructs are not bugs.  These constructs explicitly defined by
GNU C; since a diagnostic is issued, GNU C's implementation also
conforms to the Standard.

> You cannot, and are not permitted, to define "how GCC currently behaves"
> as "defines what is valid GNU C". No one agrees with your analysis. Most
^^

I'm not a person?

> importantly, GCC does not agree with your analysis.

For some definition of GCC, which is apparently you.

> It's a wild, wild, wild claim to begin with. You are arguing that any
> bug, ANY bug whatsoever, which qualifies for the title "how GCC
> currently behaves" because if a bug is currently present, then GCC
> currently behaves in a buggy manner...
>
> ... any such bug is, ***because*** GCC currently does it, now part of
> the documentation on "GNU C", a language dialect with documentation.
>
> Can you show me where on
> https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC
> documentation states that "C Extensions include anything that GCC
> currently does, no matter what, no matter how documented or undocumented"?

I see:

`-Wno-implicit-int (C and Objective-C only)'
 This option controls warnings when a declaration does not specify a
 type.  This warning is enabled by default in C99 and later dialects
 of C, and also by `-Wall'.

`-Wno-implicit-function-declaration (C and Objective-C only)'
 This option controls warnings when a function is used before being
 declared.  This warning is enabled by default in C99 and later
 dialects of C, and also by `-Wall'.  The warning is made into an
 error by `-pedantic-errors'.

> The concept of a language extension has bulletproof meaning. You cannot
> get around it, redefine it, pretend that something is when it isn't, or
> otherwise disagree with this bulletproof meaning.

The concept of a ``language extension'' is not defined anywhere.
Instead, there are three kinds of behavior not precisely specified by
the Standard:

  - undefined behavior, the behavior upon use of an erroneous 

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Sam James  writes:

> They're using > c89/gnu89 often because defaults have changed (a point
> others have raised, including Arsen and Eli Schwartz) even though they
> weren't intended to be compiled with newer C.
>
> A fair amount of other projects do explicitly ask for either c99/gnu99
> or c11/gnu11 and if they're doing that, they shouldn't be getting
> something which was removed from the C standard. But if they really want
> it, they can either downgrade to C89 (rather drastic), or set the
> proposed -fpermissive.

Too much trouble.

Let me tell you what will actually happen: people will never do what you
want them to.  Instead, they will simply write:

  extern int foo ();

above the new errors.  As a result, you will not have really
accomplished anything other than making a lot of users angry.  The
declarations will continue to be as correct as they have always been.

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 10:39 PM, Po Lu wrote:
>> If so, then as far as I can tell, that was the original plan? The flag
>> already exists, even. And the original proposal was to provide another
>> flag that doesn't even restrict you to c89.
> 
> And what will guarantee this ``always'' always remains true?


Nothing. The future has not happened yet, so it cannot be guaranteed. As
I said in a previous reply, the earth may be struck by a meteor and
annihilate all life on earth. I cannot guarantee for you that such an
event will never happen.

All I can say is that I think it is pretty unlikely and not worth
worrying about.

And similarly, I can say about your concern, that I think it is pretty
unlikely.

If you will not be satisfied by anything less than a "guarantee" then I
don't know what to say. Maybe hire a lawyer and draw up a contract that
you convince the GCC developers to sign, saying that they are not
legally allowed to remove the flag? Would this make you happy?


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 10:08 PM, Po Lu wrote:
>> I do not consider that you are being told what to do with your code.
>> Your code is not being broken. You may have to update your Makefile to
>  
> 
> My code is being broken.  There are thousands of Makefiles, Autoconf
> files containing configure tests, and so on.


There are ***not*** thousands of Makefiles that have this issue. But if
there were, then Makefiles are very easy to update, and only have to be
updated once per project, not thousands of times. So this is fine. You
may have to update your Makefile, but that is no big deal.

It's still no big deal, no matter how much you dramatize the intensity
of adding a flag to your Makefiles.


>> add a flag that turns off a changed default, but that does not
>> constitute being told what to do with your code, only being told what to
>> do with GCC.
> 
> That's GCC trying to tell me what to do with my own code.


So you concede that GCC is not telling you, only trying and failing to
tell you?

Great, so what's the problem? If GCC can't actually enforce it, and even
goes out of its way to offer you options to ignore what it's telling you
to do, then maybe...

... it's not telling you what to do with your code, only suggesting what
to do?

So ignore the suggestion.

I'm not sure what this semantics game here is trying to say. Is it
ethically and morally wrong for GCC to try to tell you what to do with
your code? Is it undignifying to have a mere machine go and lecture you,
a real human being with a consciousness and free will, what to do?

Because if that's what this is about then I think you are taking this
inanimate object way too personally.

If not, then I am simply entirely unsure what your objection is to being
"told".


>> Because that's exactly what is going on here. Features that were valid
>> C89 code are being used in a GNU99 or GNU11 code file, despite that
>> ***not*** being valid GNU99 or GNU11 code.
> 
> How GCC currently behaves defines what is valid GNU C.


No. Absolutely positively 100% no under any circumstances whatsoever no.

This has been explained multiple times by the GCC developers. e.g.
search for references to accepts-invalid.

"""
They are bugs where compiler accepts something that isn't valid in
the selected language nor considered valid extension.
So, after the fix we reject something that has been accepted before.

In the last few years (checked what was fixed in 10/11/12/13 releases so
far), we've fixed 12 such bugs explicitly marked that way:
"""

You cannot, and are not permitted, to define "how GCC currently behaves"
as "defines what is valid GNU C". No one agrees with your analysis. Most
importantly, GCC does not agree with your analysis.

It's a wild, wild, wild claim to begin with. You are arguing that any
bug, ANY bug whatsoever, which qualifies for the title "how GCC
currently behaves" because if a bug is currently present, then GCC
currently behaves in a buggy manner...

... any such bug is, ***because*** GCC currently does it, now part of
the documentation on "GNU C", a language dialect with documentation.

Can you show me where on
https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html the GCC
documentation states that "C Extensions include anything that GCC
currently does, no matter what, no matter how documented or undocumented"?


>> The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't
>> make it a GNU extension. It compiles with a warning in c11 mode too,
>> does that make it a c11 extension? No it does not.
> 
> Except it does?  Since the compiler is defining behavior that is
> otherwise undefined (i.e. the behavior of a program after a diagnostic
> is emitted after encountering an erroneous construct), it is defining
> an extension.


The concept of a language extension has bulletproof meaning. You cannot
get around it, redefine it, pretend that something is when it isn't, or
otherwise disagree with this bulletproof meaning.

The compiler defines an extension by writing about it in its
documentation on "GNU C extensions".

Anything else you have to say on the topic is automatically wrong.

Language has meaning. *Words* have meaning. The word "extension" has a
very specific meaning in the GCC documentation. You can read all about
it, here: https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html


>> I am not dictating anything to you or anyone else in this paragraph,
>> though? All I said was that if one writes a c89 program and tells the
>> compiler that, then they will not even notice this entire discussion to
>> begin with.
>>
>> What, precisely, have I dictated?
> 
> That people who are writing GNU C code should be forced to rewrite their
> code in ANSI C, in order to make use of GNU C extensions to the 1999
> Standard.


I did not dictate that you have to rewrite your code. You are replying
to something that has no relationship whatsoever to any form of
instruction, telling, or even 

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> Eli Schwartz  writes:
>
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
>>
>> Furthermore, even despite those technical reasons, GCC is *still*
>> committed to not breaking those old programs anyway. GCC merely wants to
>> make those old programs have to be compiled in an "old-programs" mode.
>>
>> Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4, just because GCC made a decision that
> results in everyone inserting:
>
>   extern int foo ();
>
> above what used to be implicit function declarations?

In addition to Jason's point about just setting CC, I'd also expect
there to be a few centralised places where the flags are set in most
projects anyway.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu via Gcc  writes:

> Eli Schwartz  writes:
>
>> This discussion thread is about having very good technical reasons -- as
>> explained multiple times, including instances where you agreed that the
>> technical reasons were good.
>>
>> Furthermore, even despite those technical reasons, GCC is *still*
>> committed to not breaking those old programs anyway. GCC merely wants to
>> make those old programs have to be compiled in an "old-programs" mode.
>>
>> Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4, just because GCC made a decision that
> results in everyone inserting:
>
>   extern int foo ();
>
> above what used to be implicit function declarations?

I've seen 0 instances of this. All of the fixes we've made have been
proper and all the fixes I've seen when I report but don't fix an
issue have been proper.

We wouldn't have proposed this if that was the case. Maybe you should
take your case to the C committee that removed the feature in the first
place and tell them to reinstate it because of.. ^


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Jason Merrill via Gcc]

On Thu, May 11, 2023 at 10:39 PM Po Lu via Gcc  wrote:
>
> Eli Schwartz  writes:
>
> > This discussion thread is about having very good technical reasons -- as
> > explained multiple times, including instances where you agreed that the
> > technical reasons were good.
> >
> > Furthermore, even despite those technical reasons, GCC is *still*
> > committed to not breaking those old programs anyway. GCC merely wants to
> > make those old programs have to be compiled in an "old-programs" mode.
> >
> > Can you explain to me how you think this goal conflicts with your goal?
>
> Because now people will have to go through dozens and dozens of
> Makefiles, configure.in, *.m4

You shouldn't have to change any of those, just configure with CC="gcc
-fwhatever".

Jason

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Po Lu  writes:

> Sam James  writes:
>
>> And I would not want to see that happen either, nor do I think Florian
>> would, or many of the other participants in this thread.
>>
>> Indeed, for some projects, where it's hopeless^Wlots of work,
>> we're using -std=c89 or -std=gnu89 as appropriate - as already stated.
>>
>> But most things are easy to fix.
>>
>> Our interest is purely in making the default stricter for better UX,
>> reducing the net amount of these bugs in the wild, and avoiding
>> regressions when we fix these problems. Trying to remove C89 entirely
>> would, if nothing else, be needlessly antagonistic, but some of the
>> replies seem to act as if we have.
>
> But programs are not using c89 or gnu89, right? They are using gnu99 and
> gnu11.

They're using > c89/gnu89 often because defaults have changed (a point
others have raised, including Arsen and Eli Schwartz) even though they
weren't intended to be compiled with newer C.

A fair amount of other projects do explicitly ask for either c99/gnu99
or c11/gnu11 and if they're doing that, they shouldn't be getting
something which was removed from the C standard. But if they really want
it, they can either downgrade to C89 (rather drastic), or set the
proposed -fpermissive.


signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Sam James  writes:

> And I would not want to see that happen either, nor do I think Florian
> would, or many of the other participants in this thread.
>
> Indeed, for some projects, where it's hopeless^Wlots of work,
> we're using -std=c89 or -std=gnu89 as appropriate - as already stated.
>
> But most things are easy to fix.
>
> Our interest is purely in making the default stricter for better UX,
> reducing the net amount of these bugs in the wild, and avoiding
> regressions when we fix these problems. Trying to remove C89 entirely
> would, if nothing else, be needlessly antagonistic, but some of the
> replies seem to act as if we have.

But programs are not using c89 or gnu89, right? They are using gnu99 and
gnu11.

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> Except this thread is not arguing to remove support for -std=c89 as far
> as I can tell?
>
> The argument is that on newer values for -std (such as the one GCC
> defaults to if no -std is specified), GCC should adapt its diagnostics
> better for the std in question. These newer -stds should stop issuing a
> warning diagnostic, and begin issuing an error diagnostic instead.
>
> The latter group most certainly does have somewhere to go other than
> proprietary compilers -- it can go to GCC with -std=c89 (or -Wno-* or
> -fpermissive or -fold-code or whatever the case may be).
>
> But I do not understand the comparison to -traditional. Which was
> already removed, and already resulted in, apparently, at least one group
> being so adamant on not-C that it switched to a proprietary compiler.
> Okay, understood. But at this point that group is no longer users of
> GCC... right?

Yes.

> So what is the moral of this story? To avoid repeating the story of
> -traditional, and instead make sure that users of -std=c89 always have a
 ^^
> flag they can use to indicate they are writing old c89 code?
>
> If so, then as far as I can tell, that was the original plan? The flag
> already exists, even. And the original proposal was to provide another
> flag that doesn't even restrict you to c89.

And what will guarantee this ``always'' always remains true?

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> This discussion thread is about having very good technical reasons -- as
> explained multiple times, including instances where you agreed that the
> technical reasons were good.
>
> Furthermore, even despite those technical reasons, GCC is *still*
> committed to not breaking those old programs anyway. GCC merely wants to
> make those old programs have to be compiled in an "old-programs" mode.
>
> Can you explain to me how you think this goal conflicts with your goal?

Because now people will have to go through dozens and dozens of
Makefiles, configure.in, *.m4, just because GCC made a decision that
results in everyone inserting:

  extern int foo ();

above what used to be implicit function declarations?

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Arsen Arsenović  writes:

> Indeed they should be - but warning vs. error holds significance.  A
> beginner is much less likely to be writing clever code that allegedly
> uses these features properly than to be building new code, and simply
> having made an error that they do not want and will suffer through
> confused.

Most programs already paste a chunk of Autoconf into their configure.ins
which turns on more diagnostics if it looks like the program is being
built by a developer.  i.e. from Emacs:

AC_ARG_ENABLE([gcc-warnings],
  [AS_HELP_STRING([--enable-gcc-warnings@<:@=TYPE@:>@],
  [control generation of GCC warnings.  The TYPE 'yes'
   means to fail if any warnings are issued; 'warn-only'
   means issue warnings without failing (default for
   developer builds); 'no' means disable warnings
   (default for non-developer builds).])],
  [case $enableval in
 yes|no|warn-only) ;;
 *)  AC_MSG_ERROR([bad value $enableval for gcc-warnings option]) ;;
   esac
   gl_gcc_warnings=$enableval],
  [# By default, use 'warn-only' if it looks like the invoker of 'configure'
   # is a developer as opposed to a builder.  This is most likely true
   # if GCC is recent enough and there is a .git directory or file;
   # however, if there is also a .tarball-version file it is probably
   # just a release imported into Git for patch management.
   gl_gcc_warnings=no
   if test -d "$srcdir"/.git && test ! -f "$srcdir"/.tarball-version; then
  # Clang typically identifies itself as GCC 4.2 or something similar
  # even if it is recent enough to accept the warnings we enable.
  AS_IF([test "$emacs_cv_clang" = yes],
 [gl_gcc_warnings=warn-only],
 [gl_GCC_VERSION_IFELSE([5], [3], [gl_gcc_warnings=warn-only])])
   fi])

So this is really not a problem.

> Indeed.  I said facilitates, not treats equally.  I think the veterans
> here won't lose much by having to pass -fpermissive, and I think that's
> a worthwhile sacrifice to make, to nurture the new without pressuring
> the old very much.

Until `-fpermissive' goes the way of `-traditional',
`-fwritable-strings'.

> On that note - lets presume a beginners role.  I've just started using
> GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
> mentions some 'implicit function generation', dunno what that means - if
> it mattered much, it'd have been an error.  I wrote a function called
> test that prints the int it got in hex, but I called it with 12.3, but
> it printed 1.. what the heck?

Have you actually seen anyone make this mistake?

> Why that happened is obvious to you and I (if you're on the same CPU as
> me), but to a beginner is utter nonsense.
>
> At this point, I can only assume one goes to revisit that warning..  I'd
> hope so at least.
>
> I doubt the beginner would know to pass
> -Werror=implicit-function-declaration in this case (or even about
> Werror...  I just told them what -Wall and to read the warnings, which
> was gleefully ignored)

I'd expect a question from the newbie, directed at a web search engine.

> Hell, I've seen professors do it, and for a simple reason: they knew how
> to write code, not how to use a compiler.  That's a big gap.
>
> The beginner here can't adapt - they don't know what -Wall means, they
> just pass it because they were told to do it (if they're lucky!).

If this is really such a bad problem, then how about clarifying the
error message?

> At the same time, they lose out on what is, IMO, one of the most useful
> pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables
> it by default.. we do).  It provides effective bug detection, when the
> code compiles right.  It regularly spots bugs that haven't happened yet
> for me.
>
> (and same goes for all the other useful analysis the toolchain can do
> when it has sufficient information to generate correct code, or more;
> some of which can't reasonably be a default)
>
> (on a related note, IMO it's a shame that the toolchain hides so many
> possibilities behind 'cult knowledge', depths of many manuals and bad
> defaults)

_FORTIFY_SOURCE is not really important enough to be considered here.
It's not even available everywhere.

> This sample is subject to selection bias.  My testing targets mostly
> more modern codebases that have long fixed these errors (if they have
> active maintainers), and exclusively Free Software, so I expect that the
> likelyhood that you'll need to run `export CC='gcc -fpermissive'
> CXX='g++ -fpermissive'` goes up the more you move towards old or more
> corporate codebases, but, for a veteran, this is no cost at all.
>
> Is it that much of a stretch to imagine that a maintainer of a codebase
> that has not seen revisions to get it past K practices would
> know that they need to pass -std=c89 (or a variant of such), or even
> -fpermissive - assuming that they could even spare to use GCC 14 as
> opposed to 2.95?

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Eli Schwartz  writes:

> I expect no such thing, but I do expect that people making decisions in
> the real world acknowledge that ***they*** (and no one else) made those
> decisions of their own volition.
>
> I am unsure what "decisions made in the real world" has to do with my
> observation that this real-world decision was a decision to invest time
> and effort and money in one direction rather than another direction --
> and the rejected other direction was the one that would make them users
> of GCC who are affected by GCC decisions.

The point is, we chose not to modify GCC for various reasons, and the
changes being proposed here will cause more people to make this choice.

> I do not consider that you are being told what to do with your code.
> Your code is not being broken. You may have to update your Makefile to
 

My code is being broken.  There are thousands of Makefiles, Autoconf
files containing configure tests, and so on.

> add a flag that turns off a changed default, but that does not
> constitute being told what to do with your code, only being told what to
> do with GCC.

That's GCC trying to tell me what to do with my own code.

> Very well then, (lots of) C++ is C.
>
> But many people do in fact argue that missing function declarations do
> not, in fact, look like C. It doesn't compile in a C compiler (using
 ^^

% cc -V
cc: Studio 12.5 Sun C 5.14 SunOS_i386 2016/05/31
% cc -Xs -Werror hello.c -o hello
% ./hello
hello world
the time is: 1683856188
% cat hello.c

struct timeval
{
  long tv_sec;
  long tv_usec;
};

main ()
{
  struct timeval tv;

  printf ("hello world\n");
  if (gettimeofday (, 0L))
exit (1);
  printf ("the time is: %ld\n", tv.tv_sec);
}

% 

> -Werror) either. Some of the warnings under discussion in this thread
> were never valid *anywhere*.

Really? Is that, or is that not, a C compiler?

> Some people like writing some code in one language version, and some
> code in another language version, and doing so in the same file or
> perhaps even the same function. Acknowledged. I would personally be
> afraid to do that, it seems incredibly dangerous even if in the highly
> specific case of implicit function declarations it happened to work.
>
> Because that's exactly what is going on here. Features that were valid
> C89 code are being used in a GNU99 or GNU11 code file, despite that
> ***not*** being valid GNU99 or GNU11 code.

How GCC currently behaves defines what is valid GNU C.

> The fact that it compiles with a warning in GNU99 or GNU11 mode doesn't
> make it a GNU extension. It compiles with a warning in c11 mode too,
> does that make it a c11 extension? No it does not.

Except it does?  Since the compiler is defining behavior that is
otherwise undefined (i.e. the behavior of a program after a diagnostic
is emitted after encountering an erroneous construct), it is defining
an extension.

> I am not dictating anything to you or anyone else in this paragraph,
> though? All I said was that if one writes a c89 program and tells the
> compiler that, then they will not even notice this entire discussion to
> begin with.
>
> What, precisely, have I dictated?

That people who are writing GNU C code should be forced to rewrite their
code in ANSI C, in order to make use of GNU C extensions to the 1999
Standard.

> Have I dictated to you that a c89 program can be described to the
> compiler by use of the -std=c89 flag? This seems to be a pretty standard
> understanding, to me.

No, see above.

> Correction: I am arguing by analogy that your statement: "what
> guarantees that -Wno-implicit will not be removed in the future" is
> arguing to absurdity.

The reason I asked for such a guarantee was that two important options
were in fact removed by the GCC developers in the past: -traditional and
-fwritable-strings.  So there is not exactly a good track record of
keeping useful options around, after features are made into those
arguments.

> Many people write strictly conforming program, and consider lack of
> conformance to be a coding error that must be fixed. It seems like a
> wise endeavor, frankly. I am not sure why you are challenging me to do
> so as though you think that I will be incapable of it and therefore be
> forced to concede that toggling the default diagnostic for very old code
> is a bad idea.

Really? So how many programs work when int is 16, 36, or 40 bits wide?
How many programs work when signed char has trap representations?
How many programs when char not 8 bits?

How many programs assume pointers can be converted into an integer type
without any loss of information?  How many programs assume that
pointers have only one possible integer representation?  (think lookup
tables using pointers to objects as keys)

How many programs assume NULL is all-bits-zero?  IOW, that this
initialization makes sense:

struct foo
{
  void *ptr;
  

Re: More C type errors by default for GCC 14

[Po Lu via Gcc]

Arsen Arsenović  writes:

> Seems that the algorithm and I agree.  I don't see any use in the int()
> guess that the compiler does, besides accepting old code (which makes it
> candidate for -fpermissive).

I believe:

  extern int foo ();

covers at least 50% of all C functions, since they are generally defined
to return int (as an error indication) with no narrow types in any
prototyped parameter list.  That's a reasonable enough guess.

> We can diagnose these without invoking expensive machinery, unlike
> mismatched declarations.

How so?  Remember that `extern int foo ()' declares a function with no
parameter specification returning int.

Thus, it could mean either:

  foo (a, b)
  char *a;
  long b;

or

  foo (x, y)
  double x;
  double y;

or perhaps even

  foo (va_alist)
  va_dcl

The function may even be defined with a prototyped parameter list, as
long as said parameter list does not contain any narrow types which are
subject to default argument promotions.

> I don't see why these not being diagnosed by default makes erroring on
> the far simpler implicit case not valuable (even if it leads to people
> just consciously inserting wrong declarations - that means they
> acknowledged it and made a poor decision).

All this will lead to is people making what you deem to be a ``poor''
decision.  Especially if the people who have to solve the build problems
are not the original author(s) of the program being built.

> They can be caught in multiple places when obvious, such as when not
> done explicitly.  These are two different errors.

An implicit function declaration is NOT an obvious error.  It simply may
be an error.  What is the error here?

a (b, c)
long c;
{
  return pokeaddr (c, b * FOO);
}

/* in another translation unit */

b ()
{
  a (1, 0L);
}

GCC is not a judge of other people's code, and shouldn't try to be one.

> I can't say.  I don't have memory of the traditional mode outside of
> cpp.

-traditional tried to make GCC a K compiler.  It wasn't completely
K, but it worked well enough for most cases.  There,

  - `extern' definitions take effect even outside the scope in which
they are declared.
  - typeof, inline, signed, const and volatile are not recognized.
  - unsigned narrow types promote to unsigned int.
  - string constants are always writable.  (BTW, -fwritable-strings
was also removed, so you can see why I'm sceptical about
any commitment to `-fpermissive' if it is ever introduced.)
  - register allocation is not performed within functions that call
setjmp.
  - bit-fields are always unsigned.
  - single precision floating point arithmetic is carried out in
double precision.
  - __STDC__ is not defined.

> The changes proposed today, however, are a few bits of entropy
> relevant in a few places - the overhead is low.

Yet it's rather pointless, as I explained above.

> It's not, though.  That's why this is being conversed about.  Even
> highly diligent people miss these (and even not-so-diligent people like
> me do - I've had more of these found by me passing -flto than I did by
> remembering to use an extra four -Werror=... flags, and that, of course,
> misses the int(...) case - which is not a useful one, usually what I
> meant there was (void), but strict-prototypes are a story for another
> day or year).

I can't say I've seen any such errors myself.  Perhaps people should be
told to run lint instead, whose sole job is to prevent these errors from
happening?

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 2:24 AM, Eli Zaretskii wrote:
> Please be serious, and please don't mock your opponents.  This is a
> serious discussion of a serious subject, not a Twitter post.


I responded with precisely the degree of seriousness as the statement I
responded to.

For the record, I believe both statements to have been serious. Not
necessarily correct, but serious.


> Back to the subject: the guarantees I would personally like to have is
> that the current GCC development team sees backward compatibility as
> an important goal, and will try not to break old programs without very
> good technical reasons.  At least in Emacs development, that is the
> consideration that is very high on our priority list when making
> development decisions.  It would be nice if GCC (and any other GNU
> project, for that matter) would do the same, because being able to
> upgrade important tools and packages without fear is something users
> value very much.  Take it from someone who uses GCC on various
> platforms since version 1.40.


This discussion thread is about having very good technical reasons -- as
explained multiple times, including instances where you agreed that the
technical reasons were good.

Furthermore, even despite those technical reasons, GCC is *still*
committed to not breaking those old programs anyway. GCC merely wants to
make those old programs have to be compiled in an "old-programs" mode.

Can you explain to me how you think this goal conflicts with your goal?


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 2:18 AM, Po Lu wrote:
> Eli Schwartz  writes:
>> Absolutely! It's a very good point. It's a point that people writing
>> traditional not-C in this day and age are doing so with highly complex
>> toolchains they have personally written to do things that no non-bespoke
>> toolchain does. As such, they are unaffected by any and all decisions
>> GCC makes. But if they were affected by such decisions, they would have
>> the technical knowledge to modify GCC to suit themselves.
> 
> Upper management types performed a cost analysis and decided that it
> would be more appropriate to license another C compiler.  Please don't
> expect that only technical ability affects decisions made in the real
> world.


I expect no such thing, but I do expect that people making decisions in
the real world acknowledge that ***they*** (and no one else) made those
decisions of their own volition.

I am unsure what "decisions made in the real world" has to do with my
observation that this real-world decision was a decision to invest time
and effort and money in one direction rather than another direction --
and the rejected other direction was the one that would make them users
of GCC who are affected by GCC decisions.


>> But your bespoke toolchain did not support the code which you need to
>> compile either. That's why you began hacking on it at all, to suit your
>> needs.
>>
>> So if neither GCC nor your bespoke toolchain support the code you need
>> to compile, and you must modify *something* to suit yourself, then it is
>> definitely possible to do it for GCC instead.
>>
>> I don't see what the welcome for making these modifications into the
>> default flagship experience for the entire free software ecosystem, has
>> to do with your being welcome to hack on GCC for your own personal use.
>>
>> Do you feel welcome by your proprietary vendor, who refuses to let you
>> touch it at all by withholding source code?
> 
> No, I do not.  I can not speak for my management.
> 
> But I also do not feel any welcome from a group of developers who are
> interested in breaking other code, some of which I have written for
> myself, and then religiously defend their decisions.
> 
> In short, I do not like being told what to do with my own code!


I do not consider that you are being told what to do with your code.
Your code is not being broken. You may have to update your Makefile to
add a flag that turns off a changed default, but that does not
constitute being told what to do with your code, only being told what to
do with GCC.


>> BRB, renaming all my python files to *.c and symlinking /usr/bin/cc to
>> /usr/bin/python.
>>
>> ...
>>
>> No, the criteria for whether something constitutes a given programming
>> language are not "the file extension says so" or "the compiler name says
>> so".
>>
>> A programming language is defined by the syntax and meaning of that
>> programming language.
> 
> OK, and the Portable C Compiler from Bell Labs followed one such
> definition of its syntax and meaning.
> 
> ANSI and ISO simply define several such variants of the C language,
> collectively known as Standard C.  1st edition K defines another, and
> each compiler, in practice, defines its own.  Just like there are
> different varieties of English, or perhaps German.
> 
>> (If we were to replace this conversation with a definition of what
>> constitutes python, then as a scripted language, all files without file
>> extensions could be python scripts. And similarly, people play
>> interesting games with C files by naming them unconventional names and
>> passing -xc to the compiler. File extension autodetection isn't everything.)
> 
> This is pure pedantry.  My point is:
> 
>   If it looks like a duck, and quacks like a duck, then it is a duck.
> 
> or, IOW:
> 
>   If it looks like C, compiles in a C compiler, then it is C.


Very well then, (lots of) C++ is C.

But many people do in fact argue that missing function declarations do
not, in fact, look like C. It doesn't compile in a C compiler (using
-Werror) either. Some of the warnings under discussion in this thread
were never valid *anywhere*.


>> Well no, because if they are sufficiently dedicated to their existing
>> code to not have changed in over 30 years then they are writing c89 code
>> and passing -std=c89, and this is acceptable as far as GCC is concerned
>> and their code will still compile.
> 
> They are not writing ``C89'' code.  They are writing ``GNU99'', or perhaps
> ``GNU11'' code.


Some people like writing some code in one language version, and some
code in another language version, and doing so in the same file or
perhaps even the same function. Acknowledged. I would personally be
afraid to do that, it seems incredibly dangerous even if in the highly
specific case of implicit function declarations it happened to work.

Because that's exactly what is going on here. Features that were valid
C89 code are being used in a GNU99 or GNU11 code file, despite that
***not*** being 

Re: More C type errors by default for GCC 14

[Sam James via Gcc]

Eli Schwartz via Gcc  writes:

> On 5/11/23 2:12 AM, Eli Zaretskii wrote:
>>> Date: Wed, 10 May 2023 23:14:20 -0400
>>> From: Eli Schwartz via Gcc 
>>>
>>> Second of all, why is this GCC's problem? You are not a user of GCC,
>>> apparently.
>> 
>> He is telling you that removing support for these old features, you
>> draw users away from GCC and towards proprietary compilers.
>> 
>> One of the arguments in this thread _for_ dropping that support was
>> that by not rejecting those old programs, GCC draws some users away
>> from GCC.  He is telling you that this change will, perhaps, draw some
>> people to GCC, but will draw others away from GCC.  The difference is
>> that the former group will start using Clang, which is still free
>> software (at least some of its versions), whereas the latter group has
>> nowhere to go but to proprietary compilers.  So the FOSS community
>> will have suffered a net loss.  Something to consider, I think.
>
>
> Except this thread is not arguing to remove support for -std=c89 as far
> as I can tell?
>

And I would not want to see that happen either, nor do I think Florian
would, or many of the other participants in this thread.

Indeed, for some projects, where it's hopeless^Wlots of work,
we're using -std=c89 or -std=gnu89 as appropriate - as already stated.

But most things are easy to fix.

Our interest is purely in making the default stricter for better UX,
reducing the net amount of these bugs in the wild, and avoiding
regressions when we fix these problems. Trying to remove C89 entirely
would, if nothing else, be needlessly antagonistic, but some of the
replies seem to act as if we have.



signature.asc
Description: PGP signature

Re: More C type errors by default for GCC 14

[Eli Schwartz via Gcc]

On 5/11/23 2:12 AM, Eli Zaretskii wrote:
>> Date: Wed, 10 May 2023 23:14:20 -0400
>> From: Eli Schwartz via Gcc 
>>
>> Second of all, why is this GCC's problem? You are not a user of GCC,
>> apparently.
> 
> He is telling you that removing support for these old features, you
> draw users away from GCC and towards proprietary compilers.
> 
> One of the arguments in this thread _for_ dropping that support was
> that by not rejecting those old programs, GCC draws some users away
> from GCC.  He is telling you that this change will, perhaps, draw some
> people to GCC, but will draw others away from GCC.  The difference is
> that the former group will start using Clang, which is still free
> software (at least some of its versions), whereas the latter group has
> nowhere to go but to proprietary compilers.  So the FOSS community
> will have suffered a net loss.  Something to consider, I think.


Except this thread is not arguing to remove support for -std=c89 as far
as I can tell?

The argument is that on newer values for -std (such as the one GCC
defaults to if no -std is specified), GCC should adapt its diagnostics
better for the std in question. These newer -stds should stop issuing a
warning diagnostic, and begin issuing an error diagnostic instead.

The latter group most certainly does have somewhere to go other than
proprietary compilers -- it can go to GCC with -std=c89 (or -Wno-* or
-fpermissive or -fold-code or whatever the case may be).

But I do not understand the comparison to -traditional. Which was
already removed, and already resulted in, apparently, at least one group
being so adamant on not-C that it switched to a proprietary compiler.
Okay, understood. But at this point that group is no longer users of
GCC... right?

So what is the moral of this story? To avoid repeating the story of
-traditional, and instead make sure that users of -std=c89 always have a
flag they can use to indicate they are writing old c89 code?

If so, then as far as I can tell, that was the original plan? The flag
already exists, even. And the original proposal was to provide another
flag that doesn't even restrict you to c89.


-- 
Eli Schwartz

Re: More C type errors by default for GCC 14

[Segher Boessenkool]

Hi Florian,

On Tue, May 09, 2023 at 08:22:44PM +0200, Florian Weimer via Gcc wrote:
> * alleged code generation bugs because the upper 32 bits of a pointer
>   are set to zero or 0x, resulting in crashes.  This can happen
>   if GCC synthesizes an implicit int declaration for a pointer-returning
>   function.
> 
> * Alleged code generation bugs because a function returning bool does
>   not set the entire register, as expected the caller.  This can happen
>   if GCC makes up a function declaration returning int for a function
>   that actually returns bool on x86-64.

Both of these cannot happen with better ABIs, by design.  Of course
every ABI has its own idiosyncrasies :-)

> I hope this makes things clearer.  I do think the current GCC defaults
> are needlessly frustrating, which is why I spent so much time on proving
> (from my perspective) that it should be feasible to change them.

Yes, I agree with this sentiment, and I think we can do a lot better
than we do now.

> We can get fairly close by injecting appropriate -Werror= options during

As you know, IMNSHO the only appropriate subset of -Werror= options is
the empty subset.

-Werror is for the user (the USER, not the build system) to ask "yes
please, I have all my priorities upside down, do fail compiling anything
that may look unexpected".  Most warnings are *heuristic*.  Other
warnings are for code that does not follow (modern) best practices.

But (most of) the diagnostics you propose to upgrade from warnings to
errors are not like this at all: they point out definite flaws, things
that just are not correct C code at all, and never were for that matter.
We always warn for those (without -Wall even) already, so upgrading
these to errors is a no-brainer really, as long as we also get
-fpermissive!


Segher

Re: More C type errors by default for GCC 14

[Arsen Arsenović via Gcc]

Eli Zaretskii  writes:

>> Cc: Jonathan Wakely , gcc@gcc.gnu.org
>> Date: Thu, 11 May 2023 10:44:47 +0200
>> From: Arsen Arsenović via Gcc 
>> 
>> the current default of accepting this code in C is harmful to those
>> who are writing new code, or are learning C.
>
> People who learn C should be advised to turn on all the warnings, and
> should be educated not to ignore any warnings.  So this is a red
> herring.

Indeed they should be - but warning vs. error holds significance.  A
beginner is much less likely to be writing clever code that allegedly
uses these features properly than to be building new code, and simply
having made an error that they do not want and will suffer through
confused.

>> This seems like a good route to me - it facilitates both veterans
>> maintaining code and beginners just learning how to write C.
>
> No, it prefers beginners (which already have the warnings, unless they
> deliberately turn them off) to veterans who know what they are doing,
> and can live with those warnings.

Indeed.  I said facilitates, not treats equally.  I think the veterans
here won't lose much by having to pass -fpermissive, and I think that's
a worthwhile sacrifice to make, to nurture the new without pressuring
the old very much.

> The right balance is exactly what we have now: emitting warnings
> without breaking builds.

I disagree - I think breaking builds here (remember, it takes 13 bytes
to fix them) is a much lower weight than the other case being shot in
the foot for an easily detectable and treatable error being made easily
missable instead, so I reckon the scale is tipped heavily towards the
veterans.

On that note - lets presume a beginners role.  I've just started using
GCC.  I run 'gcc -O2 -Wall main.c fun.c' and I get an a.out.  It
mentions some 'implicit function generation', dunno what that means - if
it mattered much, it'd have been an error.  I wrote a function called
test that prints the int it got in hex, but I called it with 12.3, but
it printed 1.. what the heck?

Why that happened is obvious to you and I (if you're on the same CPU as
me), but to a beginner is utter nonsense.

At this point, I can only assume one goes to revisit that warning..  I'd
hope so at least.

I doubt the beginner would know to pass
-Werror=implicit-function-declaration in this case (or even about
Werror...  I just told them what -Wall and to read the warnings, which
was gleefully ignored)

Anyway - I'm not making that up - this circle of 'yeah the warnings
actually matter.. a lot' has happened with everyone I've tutored that
has had little to no contact with programming before (those who had more
contact have a higher respect for the word 'warning'), and it will keep
happening.

Hell, I've seen professors do it, and for a simple reason: they knew how
to write code, not how to use a compiler.  That's a big gap.

The beginner here can't adapt - they don't know what -Wall means, they
just pass it because they were told to do it (if they're lucky!).

At the same time, they lose out on what is, IMO, one of the most useful
pieces of the toolchain: _FORTIFY_SOURCE (assuming your vendor enables
it by default.. we do).  It provides effective bug detection, when the
code compiles right.  It regularly spots bugs that haven't happened yet
for me.

(and same goes for all the other useful analysis the toolchain can do
when it has sufficient information to generate correct code, or more;
some of which can't reasonably be a default)

(on a related note, IMO it's a shame that the toolchain hides so many
possibilities behind 'cult knowledge', depths of many manuals and bad
defaults)

On the other hand... I've been writing C for a long time, and you have
been doing so for a longer time.  We see 'error: ...' in an old codebase
for a pedantic (rather, by my definition, bare essential) check and we
know where to look to fix it or ignore it.

I build old, unfamiliar codebases all the time, and I've been using a
modified toolchain that enables the error proposed today for a while; my
peers and I, who are proposing this, have gone over thousands of old
codebases, I've fixed some personally, yet the percentage of those that
have been full-out broken by this change is small (configure scripts are
almost all of it, too; Po has mentioned that they use a laxer compiler
for those - we (Gentoo) test two compilers in order to detect when these
differences happen, but keep the results of the laxer one, and then try
to fix the code upstream - often it comes down to just running autoconf
-f, even).

This sample is subject to selection bias.  My testing targets mostly
more modern codebases that have long fixed these errors (if they have
active maintainers), and exclusively Free Software, so I expect that the
likelyhood that you'll need to run `export CC='gcc -fpermissive'
CXX='g++ -fpermissive'` goes up the more you move towards old or more
corporate codebases, but, for a veteran, this is no cost at all.

Is it that much of a stretch to