Re: More C type errors by default for GCC 14

[Eli Schwartz <eschwartz93@gmail.com>]

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 ***advice***, and calling it dictation. I
reiterate: this paragraph was me ***observing*** a fact. That fact is
that if someone happens to do X, then they will not be affected by this
discussion.

(X is, in this case, "someone wrote ANSI C code and also chose to use a
flag telling the compiler that it is ANSI C".)


But, furthermore, I would like to now clarify something anyway.

You are not writing GNU C code, you never have been. GNU C code is
defined by the documentation for GNU C:
https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html

You may take this as me dictating to you that you are not to call this
code "GNU C".



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

[...]

>> by claiming that it would be bad for users if:
>>
>> - GCC 16 deletes the flag for getting back the old default
> 
> I'm sorry, but this is what people have seen repeatedly happen over the
> years.  Thus,
> 
>> If it is proposed to delete the flag for getting back the old default,
>> then and only then do people with old codebases have a valid complaint
>> that GCC is becoming unusable for their purposes.
> 
> 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.

If they want to remove -fpermissive, or -std=c89, out of an
unwillingness to provide compilers capable of being instructed to accept
and compile your coding style, then they will do so regardless of this
conversation.

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.


-- 
Eli Schwartz