The functionality described is an extension to the ISO C standard. Application developers may make use of an extension as it is supported on all POSIX.1-202x-conforming systems.

With each function or header from the ISO C standard, a statement to the effect that ``any conflict is unintentional'' is included.

The functionality described is an extension to the ISO C standard or a deviation from it. Application developers can make use of the functionality as it is supported on all POSIX.1-202x-conforming systems.

With each function or header from the ISO C standard, a statement is included to the effect that ``any conflict is unintentional'', or ``any other conflict is unintentional'' if there is an intentional conflict (deviation).

it shall accept source code conforming to the ISO C standard

it shall accept source code written in the C language as defined in section 6 of the ISO C standard

... and a linkage phase, for handling Phase 8 of the ISO C standard and extensions described here.

The reference to ``library components'' in Phase 8 shall be taken to refer to components of libraries specified using the -l option, libraries specified as file.a or file.so operands, and the equivalent of a -l c option passed to the link editor in the manner specified in the EXTENDED DESCRIPTION.

Since this standard requires that conforming applications define either _POSIX_C_SOURCE or _XOPEN_SOURCE before inclusion of any header (see [xref to XSH 2.2.1 POSIX.1 Symbols]), if c17 is used to compile source code that includes a header without defining one of these feature test macros in the required manner, the behavior of c17 itself and the results of using any files it generates are undefined. When c17 is used this way, implementations are encouraged to make visible in headers from the ISO C standard only the symbols that are allowed by that standard, and otherwise to behave the same as if _POSIX_C_SOURCE or _XOPEN_SOURCE had been defined, but portable applications cannot rely on this.

This margin code is used to denote extensions beyond the ISO C standard. For interfaces that are duplicated between POSIX.1-202x and the ISO C standard, a CX introduction block describes the nature of the duplication, with any extensions appropriately CX marked and shaded.

This margin code is used to denote extensions beyond and, in exceptional cases, deviations from the ISO C standard. For interfaces that are duplicated between POSIX.1-202x and the ISO C standard, a CX introduction block describes the nature of the duplication, with any extensions or deviations appropriately CX marked and shaded. Where deviations exist, the reasons for them are explained in the RATIONALE section of the affected interface. Deviations have become necessary because there is no longer any formal way for ISO to acknowledge defects in the ISO C standard. For the original C90 standard and the C99 revision, defect reports (DRs) were issued, but there is no equivalent mechanism for the current revision. Even if the defect is corrected in a later revision, without stating deviations POSIX.1-202x would continue to require the incorrect behavior described in the version of the ISO C standard that it references.