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^(TM) 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^(TM) 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^(TM) 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)