Skip to content

[lex.name] prohibits uses of predefined macro names and feature-test macros CWG 2818 #5296

Description

@JohelEGP

This seems to prohibit uses of predefined macro names and library feature-test macros.

3# In addition, some identifiers are reserved for use by C++ implementations and shall not be used otherwise; no diagnostic is required.
(3.1) Each identifier that contains a double underscore __ or begins with an underscore followed by an uppercase letter is reserved to the implementation for any use.
(3.2) Each identifier that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

More formally, according to [intro.compliance.general],

(2.3)
If a program contains a violation of a rule for which no diagnostic is required, this document places no requirement on implementations with respect to that program.

Permission to use predefined macro names and library feature-test macros needs to be added to [cpp.predefined] and [version.syn], respectively. For full effect, amend [lex.name]p3's "otherwise" to "unless otherwise specified".

Activity

  1. JohelEGP commented on Feb 15, 2022

    @JohelEGP
    ContributorAuthor

    I think the permission added to [version.syn] will also need something like [cpp.predefined]'s p4, that is, that a library feature-test macro is not subject of #define and #undef. But that is not relevant to the issue at hand.

  2. frederick-vs-ja commented on Feb 16, 2022

    @frederick-vs-ja
    Contributor

    IIUC this issue touches the same area as #5187.
    In addition to the standard, implementations generally provide their own feature test macros. I think we should (conditionally) allow usage of these macros.

  3. JohelEGP commented on Feb 16, 2022

    @JohelEGP
    ContributorAuthor

    IIUC this issue touches the same area as #5187.

    Indeed.

    In addition to the standard, implementations generally provide their own feature test macros. I think we should (conditionally) allow usage of these macros.

    I had considered this. But my conclusion was that implementations can define that so as not to fall under the standard's NDR. They probably already do that with __is_same and family.

  4. opensdh commented on Apr 6, 2022

    @opensdh
    Contributor

    It's my intent to resolve this along with #5187.

  5. changed the title [-][lex.name] prohibits uses of predefined macro names and feature-test macros[/-] [+][lex.name] prohibits uses of predefined macro names and feature-test macros CWG2818[/+] on Nov 12, 2023
  6. changed the title [-][lex.name] prohibits uses of predefined macro names and feature-test macros CWG2818[/-] [+][lex.name] prohibits uses of predefined macro names and feature-test macros CWG 2818[/+] on Nov 12, 2023
  7. frederick-vs-ja commented on Aug 22, 2024

    @frederick-vs-ja
    Contributor

    The original issue should be already resolved by #7099 (ba8ff83). The concerns seem fully addressed in CWG2818.

    However, it doesn't seem allowed to detect "future" standard feature-test macros yet. Not sure whether this is intended.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions