svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
standards(7)
st...s(7)Standards, Environments, Macros, Character Sets, and miscellansyt...s(7)
NAME
standards, ANSI, C, C++, ISO, POSIX, POSIX.1, POSIX.2, SUS, SUSv2,
SUSv3, SUSv4, SVID, SVID3, XNS, XNS4, XNS5, XPG, XPG3, XPG4, XPG4v2,
XPG5, XPG6, XPG7 - standards and specifications supported by Oracle So‐
laris 11.4
DESCRIPTION
Oracle Solaris 11.4 conforms to The Open Group's UNIX V7 Product Stan‐
dard which means it supports IEEE Std 1003.1-2008, commonly referred to
as POSIX.1-2008, UNIX V7, XPG7 or SUSv4 (Single UNIX Specification,
Version 4). Note that POSIX.1-2008 is simultaneously IEEE Std
1003.1-2008 and The Open Group Technical Standard Base Specifications,
Version 7. Note that SUSv4 incorporates IEEE Std 1003.1-2008 and
ISO/IEC 9945:2009 (Portable Operating System Interface (POSIX) Base
Specifications, Issue 7). New code should be written using the UNIX V7
standard. See the last section of this man page for historical informa‐
tion about which release of SunOS or Oracle Solaris first conformed to
a particular standard and what to expect when running code compiled on
a previous version of Oracle Solaris.
When using the Oracle Developer Studio 12.5 or 12.6 C compiler or the
latest version of GCC or LLVM/Clang found in Oracle Solaris 11.4, Ora‐
cle Solaris 11.4 supports:
o The ANSI X3.159-1989 Programming Language - C (C89) and
ISO/IEC 9899:1990 Programming Language - C (C90) interfaces
o ISO/IEC 9899:1990 Amendment 1:1995: C Integrity (C95)
o ISO/IEC 9899:1999 Programming Languages - C (C99)
o INCITS/ISO/IEC 9899:2011 Programming Languages - C (C11)
See the documentation for each compiler to learn how to use the -std
option to control which standard is followed when compiling C code.
If a C++ compiler such as Oracle Developer Studio, Oracle Solaris Stu‐
dio, g++, or clang++ is installed, refer to its documentation for a
discussion of which C++ standards are supported.
With regard to networking, 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 or SUSv3 for LP64 (64-bit) applica‐
tion environments because they have LP64-clean interfaces that are
portable across ILP32 and LP64 environments. Oracle Solaris 11.4 sup‐
ports both the ILP32 and LP64 environments. Future releases of Oracle
Solaris may only support LP64 environments.
Conformance
A default Oracle Solaris installation might require additional steps in
order to be fully SUSv4 compliant.
Packages
The XPG7 Conformance group package and Oracle Developer Studio must be
installed.
tab(); lw(3.67i) lw(1.83i) lw(3.67i) lw(1.83i) PackagePublisher _
pkg:/group/feature/xpg7solaris pkg:/developer/developerstudio-126/ccso‐
larisstudio
File systems
Typically, ZFS, the default root file system, is SUSv4 compliant. How‐
ever, ZFS does not meet compliance requirements in the following edge
case conditions:
o Updating ZFS file system capacity statistics.
o Modifying or removing existing data with almost full file
system.
Applications that expect strict SUSv4 compliance must operate on UFS
and would require setting up an UFS filesystem on a ZFS zvol device.
Utilities
If the behavior required by POSIX.1-2008 conflicts with historical So‐
laris utility behavior, the original Solaris version of the utility is
unchanged and a standard-conforming version of the utility is provided
in /usr/xpg7/bin. See the end of this manual page for historical detail
about prior standards versions.
An application that wants to use POSIX.1-2008 standard-conforming util‐
ities must set the PATH (sh(1) or ksh(1)) or path (csh(1)) environment
variable to specify the directories listed below in the order specified
to get the appropriate utilities. See the end of this manual page for
historical detail about specifying directories for past versions.
POSIX.1-2008, SUSv4
1. /usr/xpg7/bin
2. /usr/xpg6/bin
3. /usr/xpg4/bin
4. /usr/bin
5. Directory containing binaries for your compiler
6. Other directories containing binaries needed by the ap‐
plication
Once the PATH/path variable is set, the getconf command can be used to
confirm the settings.
When an application uses the execlp() function, execvp() function or
execvpe() function to execute a shell file, or uses the system(3C)
function, the shell used to interpret the shell file depends on the
standard to which the calling program conforms. For more information,
see the exec(2) man page.
tab(); lw(2.58i) lw(2.92i) lw(2.58i) lw(2.92i) StandardShell Used _
POSIX.1-2008, SUSv4, XPG7/usr/xpg4/bin/sh No standard speci‐
fied/usr/bin/sh
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 SUSv4), 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 on the compile command line or within the appli‐
cation source files.
POSIX.1-2008
Applications that are intended to be conforming POSIX.1-2008 applica‐
tions must define the feature test macro _POSIX_C_SOURCE=200809L, be‐
fore including any headers. Application writers must check the standard
for other macros that can be queried to determine if desired options
are supported by the implementation.
SUSv4
To build or compile an application that conforms to the SUSv4 specifi‐
cation, the application must define _XOPEN_SOURCE=700. Applications
need not set the POSIX.1-2008 feature test macro if they require both
SUS and POSIX functionality.
1989 ANSI C, 1990 ISO C, 1999 ISO C, 2011 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, predefined by the compiler based on
compiler defaults and command-line options, is set to a value of 199711
or greater, the compiler operates in a standard-conforming mode, indi‐
cating C++ standards conformance. Refer to the C++ compiler documenta‐
tion for an explanation of the values this macro can have and which
versions of the C++ standard are supported.
C++ bindings are not defined for POSIX or SUSv4, so specifying feature
test macros such as _POSIX_SOURCE, _POSIX_C_SOURCE, and _XOPEN_SOURCE
can result in compilation errors due to conflicting requirements of
standard C++ and these specifications.
Compilation with Oracle Developer Studio Compiler
The Oracle Developer Studio 12.5 and 12.6 C Compilers provide the IN‐
CITS/ISO/IEC 9899:2011 (C11) standard-conforming compilation system by
default. They also provide the ISO/IEC 9899:1999 (C99) standard-con‐
forming compilation system.
If the compiler supports the redefine_extname pragma feature, the Ora‐
cle Developer Studio C Compiler and C++ Compiler define the macro
__PRAGMA_REDEFINE_EXTNAME to indicate that they support this feature.
If the previous condition is met, 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.
When using the Oracle Developer Studio 12.5 or 12.6 C Compiler, appli‐
cations conforming to POSIX.1-2008 should be compiled using the utili‐
ties and flags indicated in the following table:
tab(); lw(1.83i) lw(1.83i) lw(1.83i) lw(1.83i) lw(1.83i) lw(1.83i)
SpecificationCompiler/FlagsFeature Test Macros _
POSIX.1-2008c99_POSIX_C_SOURCE=200809L _ SUSv4c99_XOPEN_SOURCE=700
HISTORY
History: POSIX Standards
Oracle Solaris has a history of supporting IEEE Std 1003.1 and IEEE Std
1003.2, commonly known as POSIX.1 and POSIX.2, respectively. The fol‐
lowing table lists each version of these standards with a brief de‐
scription and the SunOS or Solaris release that first conformed to it.
tab(); lw(1.37i) lw(2.75i) lw(1.37i) lw(1.37i) lw(2.75i) lw(1.37i)
POSIX StandardDescriptionRelease _ POSIX.1-1988system interfaces and
headersSunOS 4.1 _ POSIX.1-1990POSIX.1-1988 updateSolaris 2.0 _
POSIX.1b-1993realtime extensionsSolaris 2.4 _ POSIX.1c-1996threads ex‐
tensionsSolaris 2.6 _ POSIX.2-1992shell and utilitiesSolaris 2.5 _
POSIX.2a-1992interactive shell and utilitiesSolaris 2.5 _
POSIX.1-2001T{ POSIX.1-1990, POSIX.1b-1993, POSIX.1c-1996,
POSIX.2-1992, and POSIX.2a-1992 updates T}Solaris 10 _
POSIX.1-2004POSIX.1-2001 updateOracle Solaris 11 _
POSIX.1-2008POSIX.1-2004 updateOracle Solaris 11.4
History: X/Open and The Open Group Standards
Oracle Solaris also has a history of supporting the X/Open Common Ap‐
plications Environment (CAE) Portability Guide Issue 3 (XPG3) and Issue
4 (XPG4); Single UNIX Specification (SUS, also known as XPG4v2); Single
UNIX Specification, Version 2 (SUSv2); Single UNIX Specification, Ver‐
sion 3 (SUSv3); and Single UNIX Specification, Version 4 (SUSv4). 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 de‐
scription and the SunOS or Solaris release that first conformed to it.
tab(); lw(1.22i) lw(3.06i) lw(1.22i) lw(1.22i) lw(3.06i) lw(1.22i)
SpecificationDescriptionRelease _ XPG3T{ superset of POSIX.1-1988 con‐
taining utilities from SVID3 T}SunOS 4.1 _ XPG4T{ superset of
POSIX.1-1990, POSIX.2-1992, and POSIX.2a-1992 containing extensions to
POSIX standards from XPG3 T}Solaris 2.4 _ SUS (XPG4v2)T{ superset of
XPG4 containing historical BSD interfaces widely used by common appli‐
cation packages T}Solaris 2.6 _ XNS4sockets and XTI interfacesSolaris
2.6 _ SUSv2T{ superset of SUS extended to support POSIX.1b-1993,
POSIX.1c-1996, and ISO/IEC 9899 (C Standard) Amendment 1 T}Solaris 7 _
XNS5T{ superset and LP64-clean derivative of XNS4 T}Solaris 7 _ SUSv3
(XPG6)same as POSIX.1-2001Solaris 10 _ SUSv4 (XPG7)same as
POSIX.1-2008Solaris 11.4
History: Other
Solaris releases 7 through Oracle Solaris 11.4 support both the ILP32
and LP64 environments. Future releases of Oracle Solaris may only sup‐
port LP64 environments.
Solaris releases 2.0 through Oracle Solaris 11.4 support the interfaces
specified by the System V Interface Definition, Third Edition, Volumes
1 through 4 (SVID3). Note 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.
Solaris releases 7 through 10 were branded to conform to The Open
Group's UNIX 98 Product Standard. Solaris 10 through Oracle Solaris 11
were branded to conform to The Open Group's UNIX 03 Product Standard.
History: Utilities
If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 con‐
flicted with historical Solaris utility behavior, the original Solaris
version of the utility was unchanged and a standard-conforming version
of the utility was provided in /usr/xpg4/bin. If the behavior required
by POSIX.1-2001 or SUSv3 conflicted with historical Solaris utility be‐
havior, a standard conforming version was provided in /usr/xpg4/bin or
in /usr/xpg6/bin. If the behavior required by POSIX.1-2001 or SUSv3
conflicts with POSIX.2, POSIX.2a, SUS, or SUSv2, a standard conforming
version was provided in /usr/xpg6/bin.
An application that wants to use standard-conforming utilities must set
the PATH (sh(1) or ksh(1)) or path (csh(1)) environment variable to
specify the directories listed below in the order specified to get the
appropriate utilities:
SVID3, XPG3
1. /usr/bin
2. Directory containing binaries for your compiler
3. Other directories containing binaries needed by the ap‐
plication
POSIX.2, POSIX.2a, SUS, SUSv2, XPG4
1. /usr/xpg4/bin
2. /usr/bin
3. Directory containing binaries for your compiler
4. Other directories containing binaries needed by the ap‐
plication
POSIX.1-2001, SUSv3, XPG6
1. /usr/xpg6/bin
2. /usr/xpg4/bin
3. /usr/bin
4. Directory containing binaries for your compiler
5. Other directories containing binaries needed by the ap‐
plication
When an application uses the execlp() function or execvp() function to
execute a shell file, or uses the system(3C) function, the shell used
to interpret the shell file depends on the standard to which the call‐
ing program conforms. For more information, see the exec(2) man page.
tab(); lw(4.12i) lw(1.37i) lw(4.12i) lw(1.37i) StandardShell Used _ T{
POSIX.1 (1990-2008), SUS, SUSv2, SUSv3, SUSv4, XPG4, XPG5, XPG6
T}/usr/xpg4/bin/sh _ POSIX.1 (1988), SVID3, XPG3/usr/bin/sh
History: Feature Test Macros
As noted above, feature test macros are used by applications to indi‐
cate additional sets of features that are desired beyond those speci‐
fied by the C standard. The following sections outline historical in‐
formation about POSIX versions prior to POSIX.1-2008, X/Open CAE prior
to SUSv4, and SVID3.
POSIX
The following table lists the feature test macros for prior versions of
POSIX:
tab(); cw(1.37i) cw(4.12i) lw(1.37i) lw(4.12i) POSIX StandardFeature
Test Macros _ POSIX.1-1990_POSIX_SOURCE _ T{ POSIX.1-1990 and
POSIX.2-1992 C-Language Bindings Option T}_POSIX_SOURCE and
_POSIX_C_SOURCE=2 _ POSIX.1b-1993_POSIX_C_SOURCE=199309L _
POSIX.1c-1996_POSIX_C_SOURCE=199506L _
POSIX.1-2001_POSIX_C_SOURCE=200112L
X/Open CAE
The following table lists the guidelines for prior versions of X/Open
CAE specifications:
tab(); lw(1.37i) lw(4.12i) lw(1.37i) lw(4.12i) SpecificationInstruc‐
tions _ XPG3T{ The application must define _XOPEN_SOURCE. If
_XOPEN_SOURCE is defined with a value, the value must be less than 500.
T} _ XPG4T{ The application must define _XOPEN_SOURCE and set
_XOPEN_VERSION=4. If _XOPEN_SOURCE is defined with a value, the value
must be less than 500. T} _ SUS (XPG4v2)T{ The application must define
_XOPEN_SOURCE and set _XOPEN_SOURCE_EXTENDED=1. If _XOPEN_SOURCE is de‐
fined with a value, the value must be less than 500. T} _ SUSv2T{ The
application must define _XOPEN_SOURCE=500. T} _ SUSv3T{ The applica‐
tion must define _XOPEN_SOURCE=600. T}
SVID3
The SVID3 specification does not specify any feature test macros to in‐
dicate that an application is written to meet SVID3 requirements. The
SVID3 specification was written before the C standard was completed.
SEE ALSO
csh(1), getconf(1), ksh(1), sh(1), exec(2), sysconf(3C), system(3C),
environ(7), lf64(7)
Oracle Solaris 11.4 12 Sep 2023 st...s(7)