This is a bug in the <pthread.h> that ships with macOS tools:
This macro is even bogus for more than one reason! The definition in <pthread.h> is this:
#define _PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT \
defined(SWIFT_CLASS_EXTRA) && (!defined(SWIFT_SDK_OVERLAY_PTHREAD_EPOCH) || (SWIFT_SDK_OVERLAY_PTHREAD_EPOCH < 1))
The macro expansion is not properly parenthesized. The macro is used this way in the same file:
#if !_PTHREAD_SWIFT_IMPORTER_NULLABILITY_COMPAT
Which expands to:
#if !defined(SWIFT_CLASS_EXTRA) && (!defined(SWIFT_SDK_OVERLAY_PTHREAD_EPOCH) || (SWIFT_SDK_OVERLAY_PTHREAD_EPOCH < 1))
The ! only applies to the first test defined(SWIFT_CLASS_EXTRA) not to the whole boolean expression.
The compiler does not detect this problem, it just complains about the defined preprocessor operator coming from a macro expansion, which has undefined behavior as specified in the C Standard:
6.10.1 Conditional inclusion
[...]
Constraints
1 The expression that controls conditional inclusion shall be an integer constant expression except that: identifiers (including those lexically identical to keywords) are interpreted as described below; and it may contain unary operator expressions of the form
defined identifier
or
defined ( identifier )
which evaluate to 1 if the identifier is currently defined as a macro name (that is, if it is predefined or if it has been the subject of a #define preprocessing directive without an intervening #undef directive with the same subject identifier), 0 if it is not.
2 Each preprocessing token that remains (in the list of preprocessing tokens that will become the controlling expression) after all macro replacements have occurred shall be in the lexical form of a token (6.4).
Semantics
3 Preprocessing directives of the forms
# if constant-expression new-line groupopt
# elif constant-expression new-line groupopt
check whether the controlling constant expression evaluates to nonzero.
4 Prior to evaluation, macro invocations in the list of preprocessing tokens that will become the controlling constant expression are replaced (except for those macro names modified by the defined unary operator), just as in normal text. If the token defined is generated as a result of this replacement process or use of the defined unary operator does not match one of the two specified forms prior to macro replacement, the behavior is undefined. After all replacements due to macro expansion and the defined unary operator have been performed, all remaining identifiers (including those lexically identical to keywords) are replaced with the pp-number 0, and then each preprocessing token is converted into a token. The resulting tokens compose the controlling constant expression which is evaluated according to the rules of 6.6. For the purposes of this token conversion and evaluation, all signed integer types and all unsigned integer types act as if they have the same representation as, respectively, the types intmax_t and uintmax_t defined in the header <stdint.h>. This includes interpreting character constants, which may involve converting escape sequences into execution character set members. Whether the numeric value for these character constants matches the value obtained when an identical character constant occurs in an expression (other than within a #if or #elif directive) is implementation-defined. Also, whether a single-character character constant may have a negative value is implementation-defined.
This relevant phrase is If the token defined is generated as a result of this replacement process or use of the defined unary operator does not match one of the two specified forms prior to macro replacement, the behavior is undefined.
It is unclear if generated just means produced as part of the macro expansion or more specifically produced by token pasting. clang seems to consider that any defined token produced coming from a macro expansion has undefined behavior in a #if controlling expression.
For both reasons, this seems to be a bug in <pthread.h> for Apple to fix.
