Page History

According to the C standardStandard, Section section 7.1.3 [ISO/IEC 9899:2011],

...

No other identifiers are reserved. (Note that the POSIX ^® standard extends the set of identifiers reserved by the C standard Standard to include an open-ended set of its own. See Section section 2.2 Compilation environment in IEEE Std 1003.1-2008.) The behavior of a program that declares or defines an identifier in a context in which it is reserved, or defines a reserved identifier as a macro name, is undefined. See also undefined behavior 106  in Annex J of the C standardStandard. Trying to define a reserved identifier can result in its name conflicting with that used in implementation, which may or may not be detected at compile time.

...

In this noncompliant code example, because the C standard library header <inttypes.h> is specified to include <stdint.h>, the name MAX_SIZE conflicts with the name of the <stdint.h> header macro used to denote the upper limit of size_t. In addition, although the name INTFAST16_LIMIT_MAX is not defined by the C standard library, it encroaches on the reserved name space because it begins with the INT prefix and ends with the _MAX suffix. (See Section section 7.31.10 of the C standardStandard.) A typical manifestation of such a clash is a compilation error.

...

This noncompliant example provides definitions for the C standard library functions malloc() and free(). Although this practice is permitted by many traditional implementations of UNIX (e.g., the Dmalloc library), it is disallowed by the C standard Standard because it is not generally portable and may lead to undefined behavior. Common effects range from compiler errors to linker errors to abnormal program behavior at runtime. Even on systems where replacing malloc() is allowed, doing so without also replacing calloc() and realloc() is likely to cause problems as well.

...

a macro definition of errno is suppressed in order to access an actual object, or the program defines an identifier with the name errno. [ISO/IEC 9899:2011]

(See undefined behavior 114  of Annex J.)

...