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

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 [reserved.names], which are a subsection of [constraints]. [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, [macro.names] uses a "shall not", where [global.names] says that names are "reserved to the implementation". [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"?