The snippet defining the NULL-macro certainly is not C in implementation namespace, as anyone is allowed to define NULL so it expands to an implementation-defined null pointer constant, provided it was not already defined. It's rarely seen, but that won't hinder anyone. Or did I just miss something critical? --Jannis 13:08, 15 March 2006 (GMT)

What you write is mostly true, but IMO the critical thing you've missed is not emphasising "provided it was not already defined" (to which I'd add "by inclusion of a standard header that defines NULL"). If none of the standard headers defining NULL are included, it's fine to (re)define it; otherwise it belongs to the implementation and redefining it invokes undefined behaviour (this might cause problems if e.g. a compiler relies on a header file definition of NULL equating to __null and then uses internal magic to translate that into 0 or (void *)0). This applies to all of the other cases we've already used the "implementation namespace" categorisation for - e.g. function names like "strcpy" - even though I've limited the quote from N1124 below to macro names. This probably should be explained at Clc:C_Code_Conventions#Conformance_Types.

7.1.3 Reserved identifiers

1 Each header declares or defines all identifiers listed in its associated subclause

[...]

— Each macro name in any of the following subclauses ...

is reserved for use as specified if any of its associated headers is included;

unless explicitly stated otherwise (see 7.1.4).

[...]

2 ... If the program declares or defines an identifier in a

context in which it is reserved (other than as allowed by 7.1.4), or defines a reserved

identifier as a macro name, the behavior is undefined.

--Netocrat 15:22, 15 March 2006 (GMT)