XPG(5)

NAME | DESCRIPTION | SEE ALSO

NAME

standards, ANSI, C, C++, ISO, POSIX, POSIX.1, POSIX.2, SUS, SUSv2, SVID, SVID3, XNS, XNS4, XNS5, XPG, XPG3, XPG4, XPG4v2– standards and specifications supported by Solaris

DESCRIPTION

Solaris 9supports 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 9also supports the X/Open Common Applications Environment (CAE) Portability Guide Issue 3 (XPG3) and Issue 4 (XPG4), Single UNIX Specification (SUS, also known as XPG4v2), and Single UNIX Specification, Version 2 (SUSv2). Both XPG4 and SUS include Networking Services Issue 4 (XNS4). SUSv2 includes Networking Services Issue 5 (XNS5).

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 CAE 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
SUS (XPG4v2)	superset of XPG4 containing historical BSD interfaces widely used by common application packages	Solaris 2.6
XNS4	sockets and XTI interfaces	Solaris 2.6
SUSv2	superset of SUS extended to support POSIX.1b-1993, POSIX.1c-1996, and ISO/IEC 9899 (C Standard) Amendment 1	Solaris 7
XNS5	superset and LP64-clean derivative of XNS4.	Solaris 7

The XNS4 specification is safe for use only in ILP32 (32-bit) environments and should not be used for LP64 (64-bit) application environments. Use XNS5, which has LP64-clean interfaces that are portable across ILP32 and LP64 environments. Solaris releases 7 through 9 support both the ILP32 and ILP64 enviornments.

Solaris releases 7 through 9 have been branded to conform to The Open Group's UNIX 98 Product Standard.

Solaris releases 2.0 through 9 support the interfaces specified by the System V Interface Definition, Third Edition, Volumes 1 through 4 (SVID3). Note, however, that since the developers of this specification (UNIX Systems Laboratories) are no longer in business and since this specification defers to POSIX and X/Open CAE specifications, there is some disagreement about what is currently required for conformance to this specification.

When Sun WorkShop Compiler™ C 4.2 is installed, Solaris releases 2.0 through 9 support the ANSI X3.159-1989 Programming Language - C and ISO/IEC 9899:1990 Programming Language - C (C) interfaces.

When Sun WorkShop Compiler™ C 5.0 is installed, Solaris releases 7 through 9 also support ISO/IEC 9899 Amendment 1: C Integrity.

When Sun WorkShop Compiler C++ 5.0 is installed, Solaris releases 2.5.1 through 9 support ISO/IEC 14882:1998 Programming Languages - C++. Unsupported features of that standard are described in the compiler README file. The features of the C++ standard adopted from ISO/IEC 9899 Amendement 1 are not supported on Solaris 2.5.1, and are only partially supported on Solaris 2.6.

Utilities

If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 conflicts with historical Solaris utility behavior, the original Solaris version of the utility is unchanged; a new version that is standard-conforming has been provided in /usr/xpg4/bin. For applications wishing to take advantage of POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 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

Feature test macros are used by applications to indicate additional sets of features that are desired beyond those specified by the C standard. If an application uses only those interfaces and headers defined by a particular standard (such as POSIX or X/Open CAE), then it need only define the appropriate feature test macro specified by that standard. If the application is using interfaces and headers not defined by that standard, then in addition to defining the appropriate standard feature test macro, it must also define __EXTENSIONS__. Defining __EXTENSIONS__ provides the application with access to all interfaces and headers not in conflict with the specified standard. The application must define __EXTENSIONS__ either at compile time or within the applicatio'n source files.

ANSI/ISO C

No feature test macros need to be defined to indicate that an application is a conforming C application.

ANSI/ISO C++

ANSI/ISO C++ does not define any feature test macros. If the standard C++ announcement macro __cplusplus is predefined to value 199711 or greater, the compiler operates in a standard-conforming mode, indicating C++ standards conformance. The value 199711 indicates conformance to ISO/IEC 14882:1998, as required by that standard. (As noted above, conformance to the standard is incomplete.) A standard-conforming mode is not available with compilers prior to Sun WorkShop C++ 5.0.

C++ bindings are not defined for POSIX or X/Open CAE, so specifying feature test macros such as _POSIX_SOURCE and _XOPEN_SOURCE can result in compilation errors due to conflicting requirements of standard C++ and those specifications.

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 Standard	Feature Test Macros
POSIX.1-1990	_POSIX_SOURCE
POSIX.1-1990 and POSIX.2-1992 C-Language Bindings Option	_POSIX_SOURCE and _POSIX_C_SOURCE=2
POSIX.1b-1993	_POSIX_C_SOURCE=199309L
POSIX.1c-1996	_POSIX_C_SOURCE=199506L

SVID3

The SVID3 specification does not specify any feature test macros to indicate that an application is written to meet SVID3 requirements. The SVID3 specification was written before the C standard was completed.

X/Open CAE

To build or compile an application that conforms to one of the X/Open CAE specifications, use the following guidelines. Applications need not set the POSIX feature test macros if they require both CAE and POSIX functionality.

XPG3

The application must define _XOPEN_SOURCE with a value other than 500 (preferably 1).

XPG4

The application must define _XOPEN_SOURCE with a value other than 500 (preferably 1) and set _XOPEN_VERSION=4.

SUS (XPG4v2)

The application must define _XOPEN_SOURCE with a value other than 500 (preferably 1) and set _XOPEN_SOURCE_EXTENDED=1.

SUSv2

The application must define _XOPEN_SOURCE=500.

Compilation

A POSIX.2-, XPG4-, SUS-, or SUSv2-conforming implementation must include an ANSI X3.159-1989 (ANSI C Language) standard-conforming compilation system and the cc and c89 utilities. Solaris 7 through 9 were tested with the cc and c89 utilities and the compilation system provided by Sun WorkShop Compiler™ C 5.0 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, but the preferred way to build applications is described below.

An XNS4- or XNS5-conforming application must include -l XNS on any link/load command line in addition to defining the feature test macros specified for SUS or SUSv2, respectively.

If the compiler suppports the redefine_extname pragma feature (the Sun WorkShop Compiler™ C 4.2 and Sun WorkShop Compiler™ C 5.0 compilers define 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 5.0 compiler was used for all branding and certification tests for Solaris releases 7 through 9.

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 file offset symbols listed on the lf64(5) manual page, since these names are used by the implementation to name the alternative entry points.

When using Sun WorkShop Compiler™ C 5.0, applications conforming to the specifications listed above should be compiled using the utilities and flags indicated in the following table:

Specification	Compiler/Flags	Feature Test Macros
ANSI/ISO C	c89	none
SVID3	cc -Xt	none
POSIX.1-1990	c89	_POSIX_SOURCE
POSIX.1-1990 and POSIX.2-1992 C-Language Bindings Option	c89	_POSIX_SOURCE and POSIX_C_SOURCE=2
POSIX.1b-1993	c89	_POSIX_C_SOURCE=199309L
POSIX.1c-1996	c89	_POSIX_C_SOURCE=199506L
CAE XPG3	cc -Xa	_XOPEN_SOURCE
CAE XPG4	c89	_XOPEN_SOURCE and _XOPEN_VERSION=4
SUS (CAE XPG4v2) (includes XNS4)	c89	_XOPEN_SOURCE and _XOPEN_SOURCE_EXTENDED=1
SUSv2 (includes XNS5)	c89	_XOPEN_SOURCE=500

For platforms supporting the LP64 (64-bit) programming environment where the SC5.0 Compilers have been installed, SUSv2–conforming LP64 applications using XNS5 library calls should be built with command lines of the form:

c89 $(getconf XBS5_LP64_OFF64_CFLAGS) -D_XOPEN_SOURCE=500 \
    $(getconf XBS5_LP64_OFF64_LDFLAGS) foo.c -o foo \
    $(getconf XBS5_LP64_OFF64_LIBS) -lxnet

SEE ALSO

sysconf(3C), environ(5), lf64(5)

NAME | DESCRIPTION | SEE ALSO