standards(5)
NAME
standards, posix, POSIX, posix.1, POSIX.1, posix.2, POSIX.2, xnet, XNET, xnet4, XNET4, xpg, XPG, xpg3, XPG3, xpg4, XPG4, xpg4v2, XPG4v2 − standards and specifications supported by Solaris
DESCRIPTION
Solaris supports IEEE Std 1003.1 and IEEE Std 1003.2, commonly known as POSIX.1 and POSIX.2, respectively. The following table lists each version of these standards with a brief description and the SunOS or Solaris release that first conformed to it.
| POSIX Standard | Description | Release |
| POSIX.1-1988 | system interfaces and headers | SunOS 4.1 |
| POSIX.1-1990 | POSIX.1-1988 update | Solaris 2.0 |
| POSIX.1b-1993 | realtime extensions | Solaris 2.4 |
| POSIX.1c-1996 | threads extensions | Solaris 2.6 |
| POSIX.2-1992 | shell and utilities | Solaris 2.5 |
| POSIX.2a-1992 | interactive shell and utilities | Solaris 2.5 |
Solaris also supports the X/Open Common Applications Environment (CAE) Portability Guide Issue 3 (XPG3), Issue 4 (XPG4), Issue 4 Version 2 (XPG4v2), and Networking Services Issue 4 (XNET4). The following table lists each X/Open specification with a brief description and the SunOS or Solaris release that first conformed to it.
| X/Open | ||
| Specification | Description | Release |
| XPG3 | superset of POSIX.1-1988 containing utilities from SVID3 | SunOS 4.1 |
| XPG4 | superset of POSIX.1-1990, POSIX.2-1992, and POSIX.2a-1992 containing extensions to POSIX standards from XPG3 | Solaris 2.4 |
| XPG4v2 | superset of XPG4 containing historical BSD interfaces widely used by common application packages | Solaris 2.6 |
| XNET4 | sockets and XTI interfaces | Solaris 2.6 |
Utilities
If the behavior required by XPG4 conflicted with historical Solaris utility behavior, the original Solaris version of the utility was not changed; rather, a new version that was XPG4-compliant was provided in /usr/xpg4/bin. For applications wishing to take advantage of POSIX.2, POSIX.2a, XPG4, or XPG4v2 features, the PATH (sh or ksh) or path (csh) environment variables should be set with /usr/xpg4/bin preceding any other directories in which utilities specified by those specifications are found, such as /bin, /usr/bin, /usr/ucb, and /usr/ccs/bin.
Feature Test Macros
POSIX
Applications that are intended to be conforming POSIX.1 applications must define the feature test macros specified by the standard before including any headers. For the standards listed below, applications must define the feature test macros listed. Application writers must check the corresponding standards for other macros that can be queried to determine if desired options are supported by the implementation.
POSIX.1-1990 _POSIX_SOURCE
POSIX.1-1990 _POSIX_SOURCE
and
and
POSIX.2-1992
C-Language Bindings Option _POSIX_C_SOURCE=2
POSIX.1b-1993 _POSIX_C_SOURCE=199309L
POSIX.1c-1996 _POSIX_C_SOURCE=199506L
X/Open
To build or compile an application that conforms to one of the X/Open specifications, use the following guidelines. Applications need not set the POSIX feature test macros if they require both XPG and POSIX functionality.
XPG3 The application must define _XOPEN_SOURCE.
XPG4 The application must define _XOPEN_SOURCE and set _XOPEN_VERSION=4.
XPG4v2 The application must define _XOPEN_SOURCE and set _XOPEN_SOURCE_EXTENDED=1.
XNET4 The application must define _XOPEN_SOURCE and set _XOPEN_SOURCE_EXTENDED=1.
Compilation
A POSIX.2-, XPG4-, or XPG4v2-compliant implementation must include an ANSI X3.159-1989 (ANSI C Language) standard-conforming compilation system and the cc and c89 utilities. Solaris 2.6 was tested with the cc and c89 utilities and the compilation system provided by Sun WorkShop Compiler™ C 4.2 in the SPARC and x86 environments. When cc is used to link applications, /usr/ccs/lib/values-xpg4.o must be specified on any link/load command line.
An XNET4-conforming application must include −l xnet on any link/load command line.
If the compiler suppports the redefine_extname pragma feature (the Sun WorkShop Compiler™ C 4.2 compiler defines the macro __PRAGMA_REDEFINE_EXTNAME to indicate that it supports this feature), then the standard headers use #pragma redefine_extname directives to properly map function names onto library entry point names. This mapping provides full support for ISO C, POSIX, and X/Open namespace reservations. The Sun WorkShop Compiler™ C 4.2 compiler was used for all branding and certification tests for Solaris 2.6.
If this pragma feature is not supported by the compiler, the headers use the #define directive to map internal function names onto appropriate library entry point names. In this instance, applications should avoid using the explicit 64-bit symbols listed on the interface64(5) manual page, since these names are used by the implementation to name the alternative entry points.
SEE ALSO
sysconf(3C), environ(5), interface64(5)
SunOS 5.6 — Last change: 11 Apr 1997