public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "david at westcontrol dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/96284] New: Outdated C features should be made errors with newer standards
Date: Wed, 22 Jul 2020 13:16:46 +0000	[thread overview]
Message-ID: <bug-96284-4@http.gcc.gnu.org/bugzilla/> (raw)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96284

            Bug ID: 96284
           Summary: Outdated C features should be made errors with newer
                    standards
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: david at westcontrol dot com
  Target Milestone: ---

While C has tried to remain backwards compatible with each new standards
revision, some changes have been made so that particularly unsafe features from
old code are no longer supported.  gcc has (reasonably enough) tried to keep
support for old features, but when something has been deprecated for decades,
perhaps it is time for it to be treated as an error by default and require an
explicit flag.  (This is in the same style as bug 85678 making "-fno-common"
the default.)

For example, implicit function declarations from K&R C were made obsolescent in
C90, and removed from the language in C99.  But by default, they still only
cause a warning (-Wimplicit-function-declaration) in gcc, no matter what
standard is picked.

Could this be made an error by default (-Werror=implicit-function-declarations)
?  Let those who want to compile old code with implicit function declarations,
do so with an explicit flag.

             reply	other threads:[~2020-07-22 13:16 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-22 13:16 david at westcontrol dot com [this message]
2020-07-22 14:09 ` [Bug c/96284] " rguenth at gcc dot gnu.org
2020-07-22 14:51 ` redi at gcc dot gnu.org
2020-07-22 17:18 ` msebor at gcc dot gnu.org
2020-07-22 17:33 ` msebor at gcc dot gnu.org
2020-07-28  5:57 ` egallager at gcc dot gnu.org
2020-07-28  7:20 ` david at westcontrol dot com
2020-07-28  7:39 ` fw at gcc dot gnu.org
2021-12-15  7:01 ` egallager at gcc dot gnu.org
2023-12-01  7:12 ` cvs-commit at gcc dot gnu.org
2023-12-01  7:12 ` cvs-commit at gcc dot gnu.org
2023-12-01  7:12 ` cvs-commit at gcc dot gnu.org
2023-12-01  7:12 ` cvs-commit at gcc dot gnu.org
2023-12-01  7:12 ` cvs-commit at gcc dot gnu.org
2023-12-01  7:15 ` fw at gcc dot gnu.org
2023-12-01  7:15 ` fw at gcc dot gnu.org
2023-12-01  8:21 ` sjames at gcc dot gnu.org
2023-12-01  8:21 ` sjames at gcc dot gnu.org
2023-12-01  8:41 ` david at westcontrol dot com

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