[Bug c/51437] GCC should warn on the use of reserved identifier/macro names

["josh at joshtriplett dot org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51437

--- Comment #9 from Josh Triplett <josh at joshtriplett dot org> 2012-02-19 06:29:27 UTC ---
(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.

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

> 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."