From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25020 invoked by alias); 19 Feb 2012 09:33:50 -0000 Received: (qmail 25007 invoked by uid 22791); 19 Feb 2012 09:33:49 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 19 Feb 2012 09:33:36 +0000 From: "vanboxem.ruben at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/51437] GCC should warn on the use of reserved identifier/macro names Date: Sun, 19 Feb 2012 09:34:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: vanboxem.ruben at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-02/txt/msg01876.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437 --- Comment #10 from Ruben Van Boxem 2012-02-19 09:33:05 UTC --- (In reply to comment #9) > (In reply to comment #8) > > You really do want to flag both definition and usage. For instance, there's > > plenty of buggy software (especially GNU software like binutils) using __pid_t > > and similar when it should be using pid_t, etc. > > In the case of identifiers containing __ or starting with _[A-Z], that does > hold true; I hadn't considered programs using internal identifiers when > corresponding public identifiers exist. (Ideally the headers could have > avoided exposing those internal identifiers to user programs in the first > place, but I don't know any sensible way to implement that.) > > However, note that the standards also reserve various other classes of names, > such as types ending in _t, for which GCC should only flag definitions, not > uses. Only system headers should define new _t types, but user code can *use* > types like time_t or pid_t without warning. These are only reserved for POSIX, and should not always be warned about! > > (Some of the other reserved identifier categories, such as E[A-Z0-9].*, > is[a-z].*, to[a-z].*, and mem[a-z].* should go under some separate, more > pedantic warning option.) I don't see why this should happen at all. There's nothing special about these general names? > > > From an undefined behavior standpoint, defining a name in the reserved > > namespace is no worse than using a name in the referred namespace assuming the > > implementation has defined it. Both are incorrect C usage and both should be > > flagged. > > True. I had mostly wanted to avoid generating hundreds of warnings for the > same identifier. However, that seems better than missing cases like the > __pid_t you mentioned above. > > > My heuristic about -isystem would prevent flagging usage of reserved names > > resulting from implementations of system headers - for instance, if a macro in > > a system header used __uint32_t because it needs to avoid making uint32_t > > visible. > > Right. That seems like the same heuristic documented at > http://gcc.gnu.org/onlinedocs/cpp/System-Headers.html that I referenced in > comment 7: "Macros defined in a system header are immune to a few warnings > wherever they are expanded."