standards(5) Standards, Environments, and Macros standards(5)
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
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 Specifica‐
tion, 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 SunOS 4.1
containing utilities from
SVID3
XPG4 superset of POSIX.1-1990, Solaris 2.4
POSIX.2-1992, and
POSIX.2a-1992 containing
extensions to POSIX stan‐
dards from XPG3
SUS (XPG4v2) superset of XPG4 contain‐ Solaris 2.6
ing historical BSD inter‐
faces widely used by com‐
mon application packages
XNS4 sockets and XTI interfaces Solaris 2.6
SUSv2 superset of SUS extended Solaris 7
to support POSIX.1b-1993,
POSIX.1c-1996, and ISO/IEC
9899 (C Standard) Amend‐
ment 1
XNS5 superset and LP64-clean Solaris 7
derivative of XNS4.
The XNS4 specification is safe for use only in ILP32 (32-bit) environ‐
ments and should not be used for LP64 (64-bit) application environ‐
ments. Use XNS5, which has LP64-clean interfaces that are portable
across ILP32 and LP64 environments. Solaris releases 7 through 9 sup‐
port 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 specifica‐
tion (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 par‐
tially supported on Solaris 2.6.
Utilities
If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 con‐
flicts 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 stan‐
dard. 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 stan‐
dard. 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 applica‐
tion 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 applica‐
tion 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, indicat‐
ing 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_SOURCE and _POSIX_C_SOURCE=2
POSIX.2-1992
C-Language
Bindings Option
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 com‐
pleted.
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 com‐
pilation system and the cc and c89 utilities. Solaris 7 through 9 were
tested with the cc and c89 utilities and the compilation system pro‐
vided by Sun WorkShop Compiler™ C 5.0 in the SPARC and IA 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 appropri‐
ate 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 c89 _POSIX_SOURCE and
POSIX.2-1992 POSIX_C_SOURCE=2
C-Language
Bindings Option
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) c89 _XOPEN_SOURCE and
(includes XNS4) _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
sysconf(3C), environ(5), lf64(5)
SunOS 5.9 29 Aug 2001 standards(5)