Is it definitely illegal to refer to a reserved name?

Question

On the std-proposals list, the following code was given:

#include <vector> #include <algorithm>  void foo(const std::vector<int> &v) { #ifndef _ALGORITHM   std::for_each(v.begin(), v.end(), [](int i){std::cout << i; } #endif } 

Let's ignore, for the purposes of this question, why that code was given and why it was written that way (as there was a good reason but it's irrelevant here). It supposes that _ALGORITHM is a header guard inside the standard header <algorithm> as shipped with some known standard library implementation. There is no inherent intention of portability here.

Now, _ALGORITHM would of course be a reserved name, per:

[C++11: 2.11/3]: In addition, some identifiers are reserved for use by C++ implementations and standard libraries (17.6.4.3.2) and shall not be used otherwise; no diagnostic is required.

[C++11: 17.6.4.3.2/1]: Certain sets of names and function signatures are always reserved to the implementation:

• Each name that contains a double underscore _ _ or begins with an underscore followed by an uppercase letter (2.12) is reserved to the implementation for any use.
• Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

I was always under the impression that the intent of this passage was to prevent programmers from defining/mutating/undefining names that fall under the above criteria, so that the standard library implementors may use such names without any fear of conflicts with client code.

But, on the std-proposals list, it was claimed that this code is itself ill-formed for merely referring to such a reserved name. I can now see how the use of the phrase "shall not be used otherwise" from [C++11: 2.11/3]: may indeed suggest that.

One practical rationale given was that the macro _ALGORITHM could expand to some code that wipes your hard drive, for example. However, taking into account the likely intention of the rule, I'd say that such an eventuality has more to do with the obvious implementation-defined* nature of the _ALGORITHM name, and less to do with it being outright illegal to refer to it.

* "implementation-defined" in its English language sense, not the C++ standard sense of the phrase

I'd say that, as long as we're happy that we are going to have implementation-defined results and that we should investigate what that macro means on our implementation (if it exists at all!), it should not be inherently illegal to refer to such a macro provided we do not attempt to modify it.

For example, code such as the following is used all over the place to distinguish between code compiled as C and code compiled as C++:

#ifdef __cplusplus extern "C" { #endif 

and I've never heard a complaint about that.

So, what do you think? Does "shall not be used otherwise" include simply writing such a name? Or is it probably not intended to be so strict (which may point to an opportunity to adjust the standard wording)?

Answer 1

Whether it's legal or not is implementation-specific (and identifier-specific).

When the Standard gives the implementation the sole right to use these names, that includes the right to make the names available in user code. If an implementation does so, great.

But if an implementation doesn't expressly give you the right, it is clear from "shall not be used otherwise" that the Standard does not, and you have undefined behavior.

Answer 2

The important part is "reserved to the implementation". It means that the compiler vendor may use those names and even document them. Your code may then use those names as documented. This is often used for extensions like __builtin_expect, where the compiler vendor avoids any clash with your identifiers (that are declared by your code) by using those reserved names. Even the standard uses them for things like __attribute__ to make sure it doesn't break existing (legal) code when adding new features.