You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[lex.name] prohibits uses of predefined macro names and feature-test macros CWG 2818 #5296
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".
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.
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.
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.
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
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
Activity
JohelEGP commentedon Feb 15, 2022
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
#defineand#undef. But that is not relevant to the issue at hand.frederick-vs-ja commentedon Feb 16, 2022
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.
JohelEGP commentedon Feb 16, 2022
Indeed.
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_sameand family.opensdh commentedon Apr 6, 2022
It's my intent to resolve this along with #5187.
[-][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[/+][-][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[/+]frederick-vs-ja commentedon Aug 22, 2024
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.