This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 16 [library] Status: NAD Submitter: Sean Hunt Opened: 2009-10-13 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [library].
View all other issues in [library].
View all issues with NAD status.
Discussion:
I wasn't sure whether to consider this a library or a language issue, because the issue is I think it's incorrectly categorized as being part of the library, so I thought I'd send a message to both of you and let you sort it out.
Most reserved identifiers are treated as unilaterally available to the implementation, such as to implement language extensions, or provide macros documenting its functionality. However, the requirements for reserved identifers are in 16.4.5.3 [reserved.names], which are a subsection of 16.4.5 [constraints]. 16.4.5.1 [constraints.overview] appears only to apply to "C++ programs that use the facilities of the C++ standard library", meaning that, in theory, all implementations are erroneous in having any non-standard identifiers predefined for programs that do not, at some point, include a standard library header.
Furthermore, it's unclear whether the use of certain identifiers is UB
or results in an ill-formed program. In particular, 16.4.5.3.3 [macro.names] uses a "shall not", where [global.names] says that names are "reserved to the
implementation". 16.4.5.3 [reserved.names] seems only to cover the
instance of a name being described as "reserved", so are implementations
required to diagnose a program that performs, as an example, "#undef
get"?
[ 2009 Santa Cruz: ]
Move to NAD. There may in theory be multiple interpretations possible, but there's no evidence that this causes any genuine problems or uncertainty about what implementations are allowed to do. We do not believe this rises to the level of a defect.
Proposed resolution: