Proposed resolution:

This wording is relative to N5032.

1. Modify [headers] as indicated:

   […]

   -5- Except as noted in [library] through [exec] and [depr], the contents of each header cname is the same as that of the corresponding header name.h as specified in the C standard library ([intro.refs]). In the C++ standard library, however, the declarations (except for names which are defined as macros in C++) are within namespace scope ([basic.scope.namespace]) of the namespace `std`. It is unspecified whether these names (including any overloads added in [support] through [exec] and [depr]) are first declared within the global namespace scope and are then injected into namespace `std` by explicit using-declarations ([namespace.udecl]).

   -6- Names which are defined as macros in C shall be defined as macros in the C++ standard librarythe C++ standard library shall not be defined as functions, even if C grants license for implementation as functions. [Note 2: The names defined as macros in C include the following: `assert`, `offsetof`, `setjmp`, `va_arg`, `va_end`, and `va_start`. — end note]

   -7- Names that are defined as functions in C shall be defined as functions in the C++ standard librarythe C++ standard library shall not be defined as macros.(138)

Originally reported in cplusplus/draft#8579.

Currently, [headers] p5 specially mentions "except for names which are defined as macros in C", which covers `std::fpclassify` and its friends. Perhaps we don't want to require them to be initially declared in namespace `std`. Moreover, [headers] p6 seemingly requires them to be also defined as macros in C++, which doesn't seem intentional.

Perhaps we want to exactly specify whether a name denotes a function (overload set) or a macro in C++, while no name should denote both a function and a macro, and to allow a function name from C initially declared in the global namespace.