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!

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