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

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

[vanboxem.ruben at gmail dot com]

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

             Bug #: 51437
           Summary: GCC should warn on the use of reserved
                    identifier/macro names
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: vanboxem.ruben@gmail.com


For C and C++, Clang should warn when user code uses identifiers or macros that
are implementation-reserved.

For C(99), this would mean names starting with an underscore followed by
another unerscore or capitalized letter.

For C++ a single underscore is also reserved for the global namespace.

I could have messed the above rules up, but these are the cause of a lot of
unexpected bugs, and a warning would be super-easy to implement.

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

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-06 11:37:39 UTC ---
(In reply to comment #0)
> For C and C++, Clang

Ahem!

> For C++ a single underscore is also reserved for the global namespace.

That comes from C, not C++:
"All identifiers that begin with an underscore are always reserved for use as
identifiers with file scope in both the ordinary and tag name spaces."

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

[vanboxem.ruben at gmail dot com]

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

--- Comment #2 from Ruben Van Boxem <vanboxem.ruben at gmail dot com> 2011-12-06 11:50:18 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > For C and C++, Clang
> 
> Ahem!
> 
> > For C++ a single underscore is also reserved for the global namespace.
> 
> That comes from C, not C++:
> "All identifiers that begin with an underscore are always reserved for use as
> identifiers with file scope in both the ordinary and tag name spaces."

Fair enough. I warned you, I only quickly glanced at both standard documens :)

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

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-06 13:34:36 UTC ---
The C standard also reserves various names for future use in 7.26

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

[potswa at mac dot com]

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

David Krauss <potswa at mac dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |potswa at mac dot com

--- Comment #4 from David Krauss <potswa at mac dot com> 2011-12-16 11:27:45 UTC ---
The #pragma GCC system_header directive helps here by tagging places where
reserved names are OK, but accommodating headers from the operating system
which may lack that directive might require something else.

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

[bugdal at aerifal dot cx]

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

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> 2012-02-19 04:27:43 UTC ---
I would greatly like to see this as well; actually I was just about to file a
duplicate report when I found this, as a result of finding "struct _Color" in
GIMP source... >_<

I think the system headers issue could be handled very easily, with no false
positives and few false negatives. The heuristic would basically be to flag any
occurrence of reserved names except in header files found in the -isystem path,
or in text resulting from expansion of a macro defined by a header file in the
-isystem path.

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

[josh at joshtriplett dot org]

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

--- Comment #7 from Josh Triplett <josh at joshtriplett dot org> 2012-02-19 04:41:59 UTC ---
(In reply to comment #6)
> I would greatly like to see this as well; actually I was just about to file a
> duplicate report when I found this, as a result of finding "struct _Color" in
> GIMP source... >_<
> 
> I think the system headers issue could be handled very easily, with no false
> positives and few false negatives. The heuristic would basically be to flag any
> occurrence of reserved names except in header files found in the -isystem path,
> or in text resulting from expansion of a macro defined by a header file in the
> -isystem path.

You don't want to flag all occurrences of reserved names, just definitions
using reserved names.  Flagging uses will just result in duplicate warnings for
the same symbols.  Also, the code that uses a symbol doesn't really have a
choice; it has to use the symbol as defined.  Better to generate a warning on
the definition only.

Good call on the issue of "text resulting from expansion of a macro"; that
seems like precisely one of the cases where system headers will want to use
_Reserved names to avoid conflict with user-defined identifiers.

I'd suggest using precisely the heuristic GCC currently uses to avoid
generating warnings in system headers, as specified in
http://gcc.gnu.org/onlinedocs/cpp/System-Headers.html , including the bit
saying "Macros defined in a system header are immune to a few warnings wherever
they are expanded."

Arguably this also needs special handling to avoid making -Wsystem-headers any
more useless, similar to the handling of -Wunknown-pragmas, but that doesn't
seem like a necessary prerequisite for adding this feature.

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

[bugdal at aerifal dot cx]

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

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> 2012-02-19 05:47:18 UTC ---
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.

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

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.

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

[josh at joshtriplett 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."

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

[vanboxem.ruben at gmail dot com]

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

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

[potswa at mac dot com]

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

--- Comment #11 from David Krauss <potswa at mac dot com> 2012-02-19 11:09:28 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > 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!

Yes, respecting POSIX would be overkill. In particular, it's OK and common to
define such types in C++ outside the global namespace.

> > (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?

See comment #3, they are reserved in C99 §7.26 "Future library directions"
(although those patterns aren't quite right).

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

[josh at joshtriplett dot org]

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

--- Comment #12 from Josh Triplett <josh at joshtriplett dot org> 2012-02-19 18:50:34 UTC ---
(In reply to comment #10)
> (In reply to comment #9)
> > 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!

I stand corrected.  I thought that the C standard reserved types with a _t
suffix, but I just re-checked the C99 and C11 specs and they don't have that
reservation, only some more specific reservations such as the others I
mentioned.

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

[josh at joshtriplett dot org]

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

--- Comment #13 from Josh Triplett <josh at joshtriplett dot org> 2012-02-19 18:56:28 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > > (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?
> 
> See comment #3, they are reserved in C99 §7.26 "Future library directions"
> (although those patterns aren't quite right).

I wrote those patterns based on C11 section 7.30 "Future library directions". 
7.30.3 says "Macros that begin with E and a digit or E and an uppercase letter
may be added to the declarations in the <errno.h> header.".  7.30.2 says
"Function names that begin with either is or to, and a lowercase letter may be
added to the declarations in the <ctype.h> header."; 7.30.12 also reserves
those two for <wctype.h>.  7.30.11 says "Function names that begin with str,
mem, or wcs and a lowercase letter may be added to the declarations in the
<string.h> header."  AFAICT, those reservations match the regexes I gave.

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

[vanboxem.ruben at gmail dot com]

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

--- Comment #14 from Ruben Van Boxem <vanboxem.ruben at gmail dot com> 2012-02-19 21:51:37 UTC ---
I don't think adding future reserved identifiers serves any purpose. In
general, code is written against a certain version of a language's Standard,
with the current constraints, not would-be might-be constraints.

Perhaps split that into a very pedantic extra warning or something.

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |tkoenig at gcc dot gnu.org
   Last reconfirmed|                            |2021-11-18
             Status|UNCONFIRMED                 |NEW

--- Comment #15 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
There should at least be a warning for code like

double 
sin(double x) {
  return x/2 + x;
}

double
foo(double x) {
  return 1 - sin(-x);
}

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

[pavel.morozkin at gmail dot com]

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

Pavel M <pavel.morozkin at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pavel.morozkin at gmail dot com

--- Comment #16 from Pavel M <pavel.morozkin at gmail dot com> ---
To remind: macros that begin with an underscore, followed by a lowercase letter
are not reserved.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redi at gcc dot gnu.org

--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Josh Triplett from comment #5)
> I'd like to see this as well.  While issuing such a warning by default would
> cause numerous warnings with existing code, having it as an opt-in
> -Wreserved-identifiers would help greatly.

Clang does this now, with -Wreserved-identifier (N.B. singular, not
"identifiers")

> Also, the rules for C prohibit a leading underscore followed by a capital
> letter, or two adjacent underscores *anywhere* in the identifier.  So, for
> example, this__identifier, or_this_identifier__.

No, that's only in C++. C allows two adjacent underscores anywhere except the
start. C++ does not.

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

[pavel.morozkin at gmail dot com]

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

--- Comment #18 from Pavel M <pavel.morozkin at gmail dot com> ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to Josh Triplett from comment #5)
> > I'd like to see this as well.  While issuing such a warning by default would
> > cause numerous warnings with existing code, having it as an opt-in
> > -Wreserved-identifiers would help greatly.
> 
> Clang does this now, with -Wreserved-identifier (N.B. singular, not
> "identifiers")
Note that in Clang -Wreserved-identifier is not part of -Wall nor -Wextra. The
reason is "chattiness of the diagnostic in practice". Full answer:
https://github.com/llvm/llvm-project/issues/57913#issuecomment-1255493025.