public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "kkylheku at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/114526] New: ISO C does not prohibit extensions: fix misconception. Date: Thu, 28 Mar 2024 22:00:19 +0000 [thread overview] Message-ID: <bug-114526-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114526 Bug ID: 114526 Summary: ISO C does not prohibit extensions: fix misconception. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: kkylheku at gmail dot com Target Milestone: --- There seems to be a historic misconception in the development of GCC that the C standard prohibits extensions. The -Wpedantic/-pedantic options are unfortunately organized around this false idea. Firstly, for a bit of background, in the GNU Coding Standards document we have this: > But we do not follow either of these specifications rigidly, > and there are specific points on which we decided not to > follow them, so as to make the GNU system better for users. > > For instance, Standard C says that nearly all extensions to C > are prohibited. How silly! GCC implements many extensions, > some of which were later adopted as part of the standard. > If you want these constructs to give an error message as > “required” by the standard, you must specify ‘--pedantic’, > which was implemented only so that we can say “GCC is a 100% > implementation of the standard”, not because there is any > reason to actually use it. [https://www.gnu.org/prep/standards/standards.html] I suspect this might have been written, at some point, by someone actually working on the design of GCC. Or at least believing the GCC documentation. The GCC man page contains text which propagates the same falsehood, claiming that the -Wpedantic/-pedantic options "[i]ssue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, and some other programs that do not follow ISO C and ISO C++." The same text appears in the main documentation. This is false; there are no forbidden extensions. There are conforming extensions and nonconforming extensions. Nonconforming extensions are those that require a diagnostic if interpreted as ISO C, due to using new syntax or anything else diagnosable. Probably, -pedantic mode should only stick to emitting required diagnostics. For instance if program uses a nonconforming extension then -pedantic should cause that to be diagnosed (while continuing to accept the GNU extension, if it's just a warning). The following diagnostics have a wording which perpetrates the falsehood that extensions are forbidden: > warning: ISO C forbids conversion of function pointer to object pointer type [-Wpedantic] > warning: ISO C forbids conversion of object pointer to function pointer type [-Wpedantic] ISO C forbids no not such thing, and requires no diagnostic. It is a conforming extension in GCC, allowed by the standard, and even required by POSIX (so that the result of dlsym can be usefully converted to a function pointer). Diagnostics which warn about conforming extensions (and reject programs when warnings are treated as errors) arguably have no place in -pedantic mode. (They can stand on their own, or be put into some other special category.) The incorrect claims in the documentation should be removed, and pedantic mode's focus should be diagnosing situations where ISO C requires a diagnostic but GCC doesn't emit one by default. Wording in diagnostics which claims that ISO C forbids something should likewise be revised; people read these statements and take them to be true!
next reply other threads:[~2024-03-28 22:00 UTC|newest] Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-28 22:00 kkylheku at gmail dot com [this message] 2024-03-28 22:03 ` [Bug c/114526] " pinskia at gcc dot gnu.org 2024-03-28 22:06 ` pinskia at gcc dot gnu.org 2024-03-28 22:33 ` kkylheku at gmail dot com 2024-03-29 0:27 ` harald at gigawatt dot nl 2024-03-29 1:20 ` jsm28 at gcc dot gnu.org 2024-03-29 1:23 ` harald at gigawatt dot nl 2024-03-29 3:07 ` kkylheku at gmail dot com 2024-04-02 16:04 ` jsm28 at gcc dot gnu.org 2024-04-02 16:16 ` harald at gigawatt dot nl 2024-04-02 16:20 ` harald at gigawatt dot nl 2024-04-02 17:21 ` jsm28 at gcc dot gnu.org 2024-04-02 17:29 ` kkylheku at gmail dot com 2024-04-02 17:35 ` kkylheku at gmail dot com 2024-04-02 17:57 ` harald at gigawatt dot nl 2024-04-02 18:18 ` jsm28 at gcc dot gnu.org 2024-04-02 19:06 ` harald at gigawatt dot nl 2024-04-02 19:41 ` kkylheku at gmail dot com 2024-04-02 21:37 ` harald at gigawatt dot nl 2024-04-03 5:48 ` kkylheku at gmail dot com 2024-04-03 8:07 ` harald at gigawatt dot nl
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=bug-114526-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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: linkBe 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).