On 5/12/23 07:57, Po Lu via Gcc wrote:
Eli Schwartz <eschwart...@gmail.com> 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 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'.
In the "C Extensions" section ?
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 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 this
case, erroneous syntax) or unspecified behavior, then that definition is
commonly considered to be an extension of that translator. Nothing
gcc.info says will change that.
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
GNU C documentation does not decide what is an extension and what is
not. In any case, if (gcc)C Extensions does not mention extensions
currently implemented by GCC, then that is a bug in the documentation,
is it not? Documentation is supposed to reflect what the program being
documented does, not the other way around. Like the Standard says:
An implementation shall be accompanied by a document that defines all
implementation- defined and locale-specific characteristics and all
extensions.
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.
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".
Really? Then why is __GNUC__ defined, and why does it compile with
`gcc'?
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.
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.
How honest and truthful they are does not reflect whether or not the
proposed new option will be kept around. In fact, I observe that none
of them have committed to supporting such an option indefinitely.
Actually, now that I think about it, what are you actually trying to get
from this conversation ? If you're unsatisfied with a lack of commitment
from the maintainers to maintain a `-fpermissive` option indefinitely,
it seems like you can't possibly be satisfied with the current
situation, either. It seems like what you actually want is an eternal
commitment from the GCC developers to never ever change the behavior of
GCC ever in any way that could ever break any of your old broken code...
