This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/51437] GCC should warn on the use of reserved identifier/macro names
- From: "vanboxem.ruben at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sun, 19 Feb 2012 09:33:05 +0000
- Subject: [Bug c/51437] GCC should warn on the use of reserved identifier/macro names
- Auto-submitted: auto-generated
- References: <bug-51437-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437
--- Comment #10 from Ruben Van Boxem <vanboxem.ruben at gmail dot com> 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."