public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "eggert at gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c/28901] -Wunused-variable ignores unused const initialised variables Date: Fri, 18 Sep 2015 23:06:00 -0000 [thread overview] Message-ID: <bug-28901-4-5ZmE7wCQmp@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-28901-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 Paul Eggert <eggert at gnu dot org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |eggert at gnu dot org --- Comment #10 from Paul Eggert <eggert at gnu dot org> --- This topic came up on the libc-alpha mailing list. The proposed change would break compilation of tzcode, which has a private header that defines static constants not all of which are used in every file that includes the header. In tzcode the problem can be worked around by using a #define rather than a static constant, but many C programmers nowadays prefer avoiding #define when possible, and static constants let you do that in many cases. (An enum wouldn't work for the tzcode case, as the values might be outside int range.) Also, in many environments macros are invisible to the debugger but static constants are visible, so the static constants are nicer for people debugging their code. This reminds me of when gcc -Wmissing-declarations used to diagnose every C99-style inline function in an include file (GCC bug 63877). The warning was put in and tested, but the tests used only old-fashioned C programming styles, and the warning caused real problems by people using a more modern C style. It'd be fine to add an option to enable the new warning, but please don't enable them merely because -Wall or -Wunused-variable is specified.
next prev parent reply other threads:[~2015-09-18 23:06 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-28901-4@http.gcc.gnu.org/bugzilla/> 2014-01-16 23:52 ` pinskia at gcc dot gnu.org 2014-01-16 23:55 ` pinskia at gcc dot gnu.org 2014-01-17 0:26 ` hjl.tools at gmail dot com 2014-02-11 17:39 ` tromey at gcc dot gnu.org 2014-08-08 14:18 ` tromey at gcc dot gnu.org 2014-10-22 18:55 ` petschy at gmail dot com 2015-09-11 22:15 ` mark at gcc dot gnu.org 2015-09-14 9:50 ` mark at gcc dot gnu.org 2015-09-18 23:06 ` eggert at gnu dot org [this message] 2015-09-18 23:43 ` manu at gcc dot gnu.org 2015-09-19 4:51 ` eggert at gnu dot org 2015-09-19 9:27 ` manu at gcc dot gnu.org 2006-08-30 11:55 [Bug c/28901] New: " mikpe at csd dot uu dot se 2006-09-19 5:13 ` [Bug c/28901] " pinskia at gcc dot gnu dot org
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-28901-4-5ZmE7wCQmp@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).