COMPAT(5)

NAME
compat - manipulate compatibility settings

SYNOPSIS
COMMAND_MODE=legacy|unix2003

#define _POSIX_C_SOURCE
#define _APPLE_C_SOURE
#define _NONSTD_SOURCE
#define __LP64__

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 unix03 causes utility programs to obey the susv3 standards even if doing so would alter the behavior of flags used in 10.3.

COMMAND_MODE's value is case insensitive and if it is unset or set to something other than legacy or unix03 it behaves as if it were set to unix03.

Defining _NONSTD_SOURCE causes library and kernel calls to behave as closely to Mac OS X 10.3's library and kernel calls as possible. Any behavioral changes in this mode are documented in the LEGACY sections of the individual function calls.

Defining any of _POSIX_C_SOURCE, _APPLE_C_SOURE, or __LP64__ causes library and kernel calls to conform to 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, while _APPLE_C_SOURE does not.

Failing to define any of those symbols currently acts as if you have defined _NONSTD_SOURCE but it is expected that in a future OS X release the default behavior will change to be as if _APPLE_C_SOURE were defined.

STANDARDS
With COMMAND_MODE set to unix2003 utility functions conform to susv3

With _POSIX_C_SOURCE, _APPLE_C_SOURE, or __LP64__ system and library calls conform to 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.