public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: "Golubev I. N." <gin@mo.msk.ru> To: gcc-gnats@gcc.gnu.org Subject: preprocessor/4902: no macro redef warnings Date: Tue, 13 Nov 2001 15:26:00 -0000 [thread overview] Message-ID: <02493bf9548983-gin@mo.msk.ru> (raw) >Number: 4902 >Category: preprocessor >Synopsis: no macro redef warnings >Confidential: no >Severity: non-critical >Priority: medium >Responsible: unassigned >State: open >Class: doc-bug >Submitter-Id: net >Arrival-Date: Mon Nov 19 10:56:00 PST 2001 >Closed-Date: >Last-Modified: >Originator: Golubev I. N. >Release: 3.0.2 >Organization: >Environment: System: host: build: target: configured with: >Description: Neil wrote in <http://gcc.gnu.org/ml/gcc-bugs/2001-11/msg00263.html>: > you get a warning iff -pedantic `(cpp)Undefining and Redefining Macros' does not say so. Neither does it explain (or refer to explanation) why that change of requiring `-pedantic' was made (making `gcc' different from many other compilers which warn by default). Perhaps some people think that redefn warnings `trigger frequently on harmless code' (as `-pedantic' description in `(cpp)Invocation' says), but I disagree. My experience shows that more often than not they detect real bugs. >How-To-Repeat: #define a 1 #define a 2 I expect: warnings like this: 2:warning: `a' redefined 1:warning: this is the location of the previous definition I get: no warnings. >Fix: 1. Add more granularity to cpp warning options. Allow redefn warnings to be enabled without requesting all `-pedantic' diagnostics. 2. Whether it done or not, document in `(cpp)Undefining and Redefining Macros' option required to get redefn warnings (or to suppress them, if they are re-enabled by default). >Release-Note: >Audit-Trail: >Unformatted:
next reply other threads:[~2001-11-19 18:56 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-11-13 15:26 Golubev I. N. [this message] 2001-11-15 7:46 Neil Booth 2001-11-15 8:16 Zack Weinberg 2001-11-16 23:46 Neil Booth 2001-11-19 9:46 Neil Booth 2001-11-19 9:48 neil 2001-11-19 9:56 neil
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=02493bf9548983-gin@mo.msk.ru \ --to=gin@mo.msk.ru \ --cc=gcc-gnats@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).