From: David Brown <david.brown@hesbynett.no>
To: gcc@gcc.gnu.org
Subject: Re: More C type errors by default for GCC 14
Date: Sun, 14 May 2023 12:29:10 +0200 [thread overview]
Message-ID: <u3qd5m$b57$1@ciao.gmane.io> (raw)
In-Reply-To: <87353z7a7o.fsf@yahoo.com>
On 14/05/2023 07:28, Po Lu via Gcc wrote:
> Eli Schwartz <eschwartz93@gmail.com> 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 consequences of their desires,
or how limiting they are. They think they are fighting on behave of
others in the same position, arguing that they should be able to
continue to rely on undocumented and unwarranted behaviour that has
worked before. It sounds reasonable, until you look at what it actually
implies - and until you consider all the other groups who also want to
rely on /different/ selections of undocumented and unwarranted
behaviour. And then, of course, there are all those C programmers who
try hard to stick to actual documented and warranted behaviour, and
would like the best warnings and development aids to help them write
good, correct code, and who then want the results to run as efficiently
as possible.
The irony is that the people who want their compiler to behave as it
always has (for their particular type of code, and their particular
unwritten ideas of how to behave) usually complain loudest about GCC.
And GCC is, of all the compilers I have used, the best at having
/documented/ flags to give these people exactly what they are looking
for. For some, it is "-fwrapv", others
"-fno-delete-null-pointer-checks", and others it is
"-Wno-implicit-function-declaration".
David
next prev parent reply other threads:[~2023-05-14 10:29 UTC|newest]
Thread overview: 246+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-09 12:15 Florian Weimer
2023-05-09 14:16 ` Dave Blanchard
2023-05-09 15:03 ` David Edelsohn
2023-05-09 15:07 ` Sam James
2023-05-09 15:35 ` Dave Blanchard
2023-05-09 15:58 ` Jonathan Wakely
2023-05-09 16:26 ` Arsen Arsenović
2023-05-09 15:14 ` Jonathan Wakely
2023-05-09 15:22 ` Dave Blanchard
2023-05-09 16:38 ` Arsen Arsenović
2023-05-09 16:57 ` Eli Zaretskii
2023-05-09 17:05 ` Sam James
2023-05-09 18:55 ` Eli Zaretskii
2023-05-09 17:15 ` Jonathan Wakely
2023-05-09 19:04 ` Eli Zaretskii
2023-05-09 19:07 ` Jakub Jelinek
2023-05-09 19:22 ` Eli Zaretskii
2023-05-09 20:13 ` David Edelsohn
2023-05-09 20:21 ` Arsen Arsenović
2023-05-10 2:38 ` Eli Zaretskii
2023-05-10 8:36 ` Arsen Arsenović
2023-05-10 11:52 ` Eli Zaretskii
2023-05-10 11:56 ` Jonathan Wakely
2023-05-10 12:25 ` Eli Zaretskii
2023-05-10 12:30 ` Jonathan Wakely
2023-05-10 12:44 ` Eli Zaretskii
2023-05-15 12:28 ` Richard Earnshaw (lists)
2023-05-15 20:17 ` Eric Gallager
2023-05-16 7:05 ` Florian Weimer
2023-05-16 15:56 ` Jason Merrill
2023-05-09 20:40 ` Jonathan Wakely
2023-05-09 22:27 ` David Edelsohn
2023-05-09 22:37 ` Joel Sherrill
2023-05-09 22:45 ` Jonathan Wakely
2023-05-10 10:40 ` Eric Gallager
2023-05-10 10:45 ` Sam James
2023-05-10 10:56 ` Neal Gompa
2023-05-10 12:06 ` Eli Zaretskii
2023-05-10 12:10 ` Neal Gompa
2023-05-10 12:41 ` Eli Zaretskii
2023-05-10 10:48 ` Jonathan Wakely
2023-05-10 10:51 ` Jonathan Wakely
2023-05-10 12:00 ` Eli Zaretskii
2023-05-10 12:42 ` Sam James
2023-05-10 15:10 ` Joel Sherrill
2023-05-10 15:14 ` Jakub Jelinek
2023-05-10 16:36 ` Joel Sherrill
2023-05-10 16:44 ` Jakub Jelinek
2023-05-10 17:05 ` Jonathan Wakely
2023-05-10 18:37 ` James K. Lowden
2023-05-10 23:26 ` Jonathan Wakely
2023-05-11 18:47 ` Jason Merrill
2023-05-10 23:33 ` Sam James
2023-05-11 5:48 ` Eli Zaretskii
2023-05-11 2:28 ` Po Lu
2023-05-11 2:09 ` Po Lu
2023-05-11 2:14 ` Sam James
2023-05-11 2:23 ` Po Lu
2023-05-11 3:14 ` Eli Schwartz
2023-05-11 3:56 ` Po Lu
2023-05-11 4:46 ` Eli Schwartz
2023-05-11 4:49 ` Eli Schwartz
2023-05-11 6:23 ` Po Lu
2023-05-11 6:18 ` Po Lu
2023-05-11 22:41 ` Eli Schwartz
2023-05-12 2:08 ` Po Lu
2023-05-12 3:07 ` Eli Schwartz
2023-05-12 5:57 ` Po Lu
2023-05-12 11:05 ` Gabriel Ravier
2023-05-12 13:53 ` Po Lu
2023-05-12 14:03 ` Jonathan Wakely
2023-05-14 12:35 ` Mark Wielaard
2023-05-12 11:48 ` 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
2023-05-12 13:07 ` Is the GNUC dialect anything that GCC does when given source code containing UB? Po Lu
2023-05-12 6:56 ` More C type errors by default for GCC 14 Eli Zaretskii
2023-05-12 7:28 ` Jonathan Wakely
2023-05-12 10:36 ` Eli Zaretskii
2023-05-12 13:19 ` Po Lu
2023-05-12 13:25 ` Gabriel Ravier
2023-05-13 0:45 ` Po Lu
2023-05-13 5:30 ` Thomas Koenig
2023-05-13 5:53 ` Po Lu
2023-05-14 5:10 ` Eli Schwartz
2023-05-14 5:38 ` Po Lu
2023-05-14 9:46 ` David Brown
2023-05-14 10:21 ` Jonathan Wakely
2023-05-14 10:23 ` Jonathan Wakely
2023-05-14 5:08 ` Eli Schwartz
2023-05-14 5:28 ` Po Lu
2023-05-14 5:56 ` Eli Schwartz
2023-05-14 11:55 ` Po Lu
2023-05-14 12:22 ` Arsen Arsenović
2023-05-15 1:05 ` Po Lu
2023-05-14 6:03 ` Eli Schwartz
2023-05-14 8:47 ` Jonathan Wakely
2023-05-14 12:05 ` Po Lu
2023-05-14 12:48 ` Nicholas Vinson
2023-05-14 10:29 ` David Brown [this message]
2023-05-12 15:51 ` Jason Merrill
2023-05-17 10:06 ` Florian Weimer
2023-05-12 11:26 ` David Brown
2023-05-11 6:24 ` Eli Zaretskii
2023-05-11 22:43 ` Eli Schwartz
2023-05-12 2:38 ` Po Lu
2023-05-12 2:55 ` Jason Merrill
2023-05-12 6:01 ` Po Lu
2023-05-12 6:40 ` Jonathan Wakely
2023-05-12 13:23 ` Po Lu
2023-05-12 10:49 ` Pedro Alves
2023-05-12 13:26 ` Po Lu
2023-05-12 11:55 ` Eli Schwartz
2023-05-12 13:54 ` Po Lu
2023-05-12 6:49 ` Eli Zaretskii
2023-05-12 2:56 ` Sam James
2023-05-12 6:03 ` Po Lu
2023-05-12 3:06 ` Sam James
2023-05-12 6:25 ` Eli Zaretskii
2023-05-12 11:23 ` Gabriel Ravier
2023-05-11 6:12 ` Eli Zaretskii
2023-05-11 7:04 ` Jonathan Wakely
2023-05-11 22:30 ` Eli Schwartz
2023-05-11 22:35 ` Sam James
2023-05-12 2:40 ` Po Lu
2023-05-12 2:52 ` Sam James
2023-05-12 5:32 ` Po Lu
2023-05-12 2:39 ` Po Lu
2023-05-12 3:18 ` Eli Schwartz
2023-05-12 6:17 ` Eli Zaretskii
2023-05-11 7:59 ` David Brown
2023-05-09 21:00 ` Thomas Koenig
2023-05-09 21:17 ` Arsen Arsenović
2023-05-10 13:57 ` Florian Weimer
2023-05-10 11:00 ` David Brown
2023-05-11 10:49 ` James K. Lowden
2023-05-11 1:38 ` Po Lu
2023-05-11 1:43 ` Sam James
2023-05-11 2:20 ` Po Lu
2023-05-09 20:57 ` Florian Weimer
2023-05-10 2:33 ` Eli Zaretskii
2023-05-10 8:04 ` Jonathan Wakely
2023-05-10 8:46 ` Richard Biener
2023-05-10 12:26 ` Florian Weimer
2023-05-10 11:30 ` Eli Zaretskii
2023-05-10 12:03 ` Jakub Jelinek
2023-05-10 12:36 ` Eli Zaretskii
2023-05-10 12:41 ` Gabriel Ravier
2023-05-10 14:14 ` Eli Zaretskii
2023-05-10 14:22 ` Jakub Jelinek
2023-05-10 15:30 ` Eli Zaretskii
2023-05-10 16:02 ` Jakub Jelinek
2023-05-10 16:31 ` Eli Zaretskii
2023-05-10 16:33 ` Richard Biener
2023-05-10 16:57 ` Eli Zaretskii
2023-05-10 17:08 ` Joseph Myers
2023-05-10 18:18 ` Eli Zaretskii
2023-05-12 15:02 ` Florian Weimer
2023-05-12 17:52 ` Florian Weimer
2023-05-12 17:55 ` Gabriel Ravier
2023-05-12 18:00 ` Florian Weimer
2023-05-12 18:08 ` Alexander Monakov
2023-05-12 18:14 ` Florian Weimer
2023-05-15 12:51 ` Michael Matz
2023-05-16 8:55 ` Florian Weimer
2023-05-16 10:39 ` Alexander Monakov
2023-05-16 11:01 ` Jakub Jelinek
2023-05-16 11:09 ` Jonathan Wakely
2023-05-16 11:15 ` Florian Weimer
2023-05-12 19:44 ` Joseph Myers
2023-05-12 20:43 ` Florian Weimer
2023-05-12 20:18 ` Jason Merrill
2023-05-12 20:57 ` Florian Weimer
2023-05-12 21:20 ` Sam James
2023-05-12 21:21 ` Sam James
2023-05-12 21:37 ` Florian Weimer
2023-05-12 21:47 ` Sam James
2023-05-12 21:59 ` Florian Weimer
2023-05-10 15:58 ` David Brown
2023-05-10 16:28 ` Eli Zaretskii
2023-05-11 6:52 ` David Brown
2023-05-11 7:39 ` Eli Zaretskii
2023-05-10 14:31 ` Thomas Koenig
2023-05-10 15:37 ` Eli Zaretskii
2023-05-11 2:38 ` Po Lu
2023-05-11 7:38 ` Arsen Arsenović
2023-05-11 8:31 ` Po Lu
2023-05-11 8:44 ` Arsen Arsenović
2023-05-11 9:28 ` Po Lu
2023-05-11 21:10 ` Arsen Arsenović
2023-05-12 1:41 ` Po Lu
2023-05-11 10:35 ` Eli Zaretskii
2023-05-11 19:25 ` Arsen Arsenović
2023-05-12 2:36 ` Po Lu
2023-05-12 12:30 ` Gabriel Ravier
2023-05-12 13:56 ` Po Lu
2023-05-12 7:53 ` Eli Zaretskii
2023-05-12 8:15 ` Jakub Jelinek
2023-05-12 10:40 ` Eli Zaretskii
2023-05-12 8:45 ` Christian Groessler
2023-05-12 10:14 ` Jonathan Wakely
2023-05-12 9:11 ` Thomas Koenig
2023-05-11 8:53 ` Jonathan Wakely
2023-05-11 9:29 ` Po Lu
2023-05-10 8:49 ` David Brown
2023-05-10 11:37 ` Eli Zaretskii
2023-05-10 11:49 ` Jonathan Wakely
2023-05-10 12:22 ` Eli Zaretskii
2023-05-10 13:30 ` David Brown
2023-05-10 14:39 ` Eli Zaretskii
2023-05-10 15:21 ` Paul Koning
2023-05-10 16:20 ` David Brown
2023-05-10 16:48 ` Eli Zaretskii
2023-05-10 12:32 ` Sam James
2023-05-10 12:47 ` Eli Zaretskii
2023-05-09 19:33 ` Arsen Arsenović
2023-05-09 15:25 ` David Edelsohn
2023-05-11 1:25 ` Po Lu
2023-05-11 1:30 ` Sam James
2023-05-11 1:33 ` Sam James
2023-05-11 2:18 ` Po Lu
2023-05-11 6:44 ` Jonathan Wakely
2023-05-11 8:32 ` Po Lu
2023-05-11 8:52 ` Jonathan Wakely
2023-05-11 7:36 ` Arsen Arsenović
2023-05-11 8:23 ` Po Lu
2023-05-09 18:22 ` Florian Weimer
2023-05-11 21:32 ` Segher Boessenkool
2023-05-09 15:16 ` Richard Biener
2023-05-09 16:05 ` Jakub Jelinek
2023-05-09 16:11 ` Sam James
2023-05-09 16:13 ` David Edelsohn
[not found] ` <BBE9950C-28AA-4A1C-A4C5-7F486538004E@gmail.com>
2023-05-09 16:44 ` Florian Weimer
2023-05-09 16:58 ` Ian Lance Taylor
2023-05-09 17:08 ` Jason Merrill
2023-05-09 17:16 ` Sam James
2023-05-09 16:59 ` Florian Weimer
2023-05-09 17:07 ` Sam James
2023-05-09 17:35 ` Florian Weimer
2023-05-11 15:21 ` Peter0x44
2023-05-12 9:33 ` Martin Jambor
2023-05-12 12:30 ` Jakub Jelinek
2023-05-15 12:46 ` Michael Matz
2023-05-15 13:14 ` Richard Earnshaw (lists)
2023-05-10 12:41 Marcin Jaczewski
2023-05-10 14:19 ` Eli Zaretskii
2023-05-10 13:10 Basile Starynkevitch
2023-05-10 14:20 ` David Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='u3qd5m$b57$1@ciao.gmane.io' \
--to=david.brown@hesbynett.no \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).