---
name: "compat"
section: "5"
platform: "macos"
package: "Libc"
version: "1752.120.2"
release: "macOS 26.5"
platforms: ["macos"]
url: "https://new.carta.tech/compat/5"
---

# compat(5)

manipulate compatibility settings

## NAME

**compat** – manipulate compatibility settings

## SYNOPSIS

COMMAND\_MODE=legacy\|unix2003\
 SYSTEM\_VERSION\_COMPAT=1

**#define \_POSIX\_C\_SOURCE**

**#define \_DARWIN\_C\_SOURCE**

**#define \_NONSTD\_SOURCE**

**defined(\_\_LP64\_\_)**

**#include \<sys/cdefs.h\>**

**defined(\_DARWIN\_FEATURE\_UNIX\_CONFORMANCE)**

## DESCRIPTION

Setting the environment variable COMMAND\_MODE to the value legacy causes utility programs to behave as closely to Mac OS X 10.3's utility programs as possible.  When in this mode all of 10.3's flags are accepted, and in some cases extra flags are accepted, but no flags that were used in 10.3 will have been removed or changed in meaning.  Any behavioral changes in this mode are documented in the LEGACY sections of the individual utilities.

Setting the environment variable COMMAND\_MODE to the value unix2003 causes utility programs to obey the Version 3 of the Single UNIX Specification (“SUSv3”) standards even if doing so would alter the behavior of flags used in 10.3.

The value of COMMAND\_MODE is case insensitive and if it is unset or set to something other than legacy or unix2003 it behaves as if it were set to unix2003.

Setting the environment variable SYSTEM\_VERSION\_COMPAT to 1 causes the system version to be reported as 10.16 when running on macOS 11 or later.

## COMPILATION

Defining \_NONSTD\_SOURCE will result in a compilation error. This is no longer supported.

Defining \_POSIX\_C\_SOURCE or \_DARWIN\_C\_SOURCE causes library and kernel calls to conform to the SUSv3 standards even if doing so would alter the behavior of functions used in 10.3. Defining \_POSIX\_C\_SOURCE also removes functions, types, and other interfaces that are not part of SUSv3 from the normal C namespace, unless \_DARWIN\_C\_SOURCE is also defined (i.e., \_DARWIN\_C\_SOURCE is \_POSIX\_C\_SOURCE with non-POSIX extensions). In any of these cases, the \_DARWIN\_FEATURE\_UNIX\_CONFORMANCE feature macro will be defined to the SUS conformance level (it is undefined otherwise).

Starting in Mac OS X 10.5, if none of the macros \_NONSTD\_SOURCE, \_POSIX\_C\_SOURCE or \_DARWIN\_C\_SOURCE are defined, and the environment variable MACOSX\_DEPLOYMENT\_TARGET is either undefined or set to 10.5 or greater (or equivalently, the [clang(1)](/clang/1.md) option **-mmacosx-version-min** is either not specified or set to 10.5 or greater), then UNIX conformance will be on by default, and non-POSIX extensions will also be available (this is the equivalent of defining \_DARWIN\_C\_SOURCE).

In order to provide both legacy and conformance versions of functions, two versions of affected functions are provided.  Legacy variants have symbol names with no suffix in order to maintain ABI compatibility.  Conformance versions have a $UNIX2003 suffix appended to their symbol name.  These $UNIX2003 suffixes are automatically appended by the compiler tool-chain and should not be used directly.

All currently supported platforms only have conformance variants available and do not have the legacy $UNIX2003 suffix.

| | | | | |
| --- | --- | --- | --- | --- |
| user defines | deployment | namespace | conformance | suffix |
|  | target |
| *(none)* | (any) | full | SUSv3 conformance | (none) |
| *\_NONSTD\_SOURCE* | (any) | (error) |
| *\_DARWIN\_C\_SOURCE* | (any) | full | SUSv3 conformance | (none) |
| *\_POSIX\_C\_SOURCE* | (any) | strict | SUSv3 conformance | (none) |

## STANDARDS

With COMMAND\_MODE set to anything other than legacy, utility functions conform to  Version 3 of the Single UNIX Specification (“SUSv3”).

With \_POSIX\_C\_SOURCE or \_DARWIN\_C\_SOURCE system and library calls conform to Version 3 of the Single UNIX Specification (“SUSv3”).

## BUGS

Different parts of a program can be compiled with different compatibility settings. The resultant program will normally work as expected, for example a regex created by the SUSv3 **regcomp**(*3*) can be passed to the legacy **regfree**(*3*) with no unexpected results.  Some cases are less clear cut, for example what does the programmer intend when they use the SUSv3 **regcomp**(*3*) to compile a regex, but the legacy **regexec**(*3*) to execute it?  Any interpretation will surprise someone.