stdsyms(5)

This symbol is automatically defined by the ANSI-C preprocessor and is automatically defined when specifying an ANSI-C compile (cc -Aa). Using the strict ANSI option -Aa requests a pure ANSI-C namespace, which is the smallest subset of the HP-UX namespace available. The -Aa option also enables the inclusion of ANSI-C-style function prototypes for increased type checking. Note that the default namespace when using the -Aa option is the ANSI-C namespace; therefore a broader namespace must be requested if it is desired.

This symbol is automatically defined by the ANSI-C preprocessor on some implementations. If defined, it indicates the version of the standard it is complying with.

As documented in the IEEE POSIX.1 standard, the programmer is required to define the _POSIX_SOURCE feature test macro to obtain the POSIX.1 namespace and POSIX.1 functionality. This feature test macro can be defined, either by using compiler options (-D_POSIX_SOURCE) or by using #define directives in the source files before any #include directives. Note that the default POSIX namespace is the POSIX.1-1990 namespace. It is necessary to define the _POSIX1_1988 feature test macro in addition to the _POSIX_SOURCE macro in order to obtain the POSIX.1-1988 namespace.

As documented in the IEEE POSIX.2 standard, the programmer is required to define the _POSIX_C_SOURCE feature test macro with a value of 2 to obtain the POSIX.1 and POSIX.2 namespaces and functionality. This feature test macro can be defined, either by using compiler options (-D_POSIX_C_SOURCE=2) or by using #define directives in the source files before any #include directives.

As documented in the X/Open Portability Guide (XPG), the programmer is required to define the _XOPEN_SOURCE feature test macro to obtain X/Open functionality. This feature test macro can be defined, either by using compiler options (-D_XOPEN_SOURCE) or by using #define directives in the source files before any #include directives. Although XPG3 does not specify any namespace pollution rules, XPG4 and its subsequent versions have instituted such rules. Therefore, the HP-UX operating system provides clean namespaces whenever _XOPEN_SOURCE is defined.

The current default X/Open namespace is that corresponding to XPG4. Broader namespace can be requested by setting _XOPEN_SOURCE to a value as specified by the standard document.

As documented in the XPG, the programmer is required to define the _XOPEN_SOURCE_EXTENDED feature test macro to obtain XPG4 v2 namespace and functionality. This feature test macro can be defined either by using compiler option (-D_XOPEN_SOURCE_EXTENDED) or by using #define directives in the source files before any #include directives.

As documented in the "OSF AES/OS" standard, the programmer is required to define the _AES_SOURCE feature test macro to obtain OSF functionality. This feature test macro can be defined, either by using compiler options (-D_AES_SOURCE) or by using #define directives in the source files before any #include directives. Although the AES does not specify any namespace pollution rules, the other standards have instituted such rules. Therefore HP-UX provides a clean namespace whenever _AES_SOURCE is defined. Use of _AES_SOURCE is strongly discouraged as this functionality will be removed in a future release of HP-UX.

The programmer can define the _HPUX_SOURCE feature test macro to obtain the HP-UX namespace and complete HP-UX functionality. Note that the HP-UX namespace is currently a superset of all of the above mentioned namespaces. When using the compiler with default options (cc) or the compiler with compatibility-mode options (cc command without the -Aa option), the HP-UX namespace is provided by default (see cc(1)). The programmer must request one of the other namespaces as described above to obtain the appropriate subset of the HP-UX namespace. When using the strict ANSI-C-mode compiler (cc -Aa), the programmer must specifically request a broader namespace.

The _HPUX_SOURCE feature test macro can be defined, either by using compiler options (-D_HPUX_SOURCE) or by using #define directives in the source files before any #include directives.

This symbol is automatically defined by the HP C++ compiler. Defining this macro enables the C++ function prototypes in system header files.

The default namespace for HP C++ is the ANSI-C namespace. To obtain another namespace define the appropriate feature test macro.

HP C++ uses the ANSI-C preprocessor by default. To get the compatibility mode preprocessor, use the -Ac option of the cc command (see cc(1)). The compatibility mode preprocessor uses the HP-UX namespace (_HPUX_SOURCE).

This feature test macro should be defined when the POSIX.1-1988 namespace is required. It should be used in conjunction with the _POSIX_SOURCE macro if the default POSIX.1-1990 namespace is not desired.

This macro is defined automatically whenever _AES_SOURCE or _XPG3 is requested.

The _XPG3 feature test macro is provided so that the programmer can obtain the XPG3 namespace, since it differs slightly from the _XPG4 namespace. In order to obtain the XPG3 namespace, the programmer must define both the _XOPEN_SOURCE and _XPG3 feature test macros. The _XOPEN_SOURCE and _XPG3 feature test macros can be defined, either by using compiler options (-D_XOPEN_SOURCE -D_XPG3) or by using #define directives in the source files before any #include directives. Use of this macro is strongly discouraged as this functionality will be removed in a future release of HP-UX.

The _XPG4 feature test macro is defined automatically if the programmer has requested the XPG4 namespace (that is, defined _XOPEN_SOURCE, but not some other conflicting namespace such as _XPG3).

The _SVID2 macro can be defined when using the compatibility mode compiler to obtain SVID2 function return types in the HP-UX namespace. The default return types of many functions have since been changed in the HP-UX operating system to align with the ANSI-C, POSIX, X/Open, and OSF standards. Use of this macro is strongly discouraged as this functionality will be removed in a future release of HP-UX.

The SVID3 macro can be defined to obtain SVID3 function prototypes. The compiler flag, -D_SVID3, needs to be defined to indicate that an application is written to meet SVID3 requirements. At the time the function prototypes were introduced in ANSI C, the functions exposed by this flag were only defined in SVID3.