standards(5)standards(5)NAME
standards, ANSI, ISO, OSF_SOURCE, POSIX, XPG4, XPG4-UNIX, XBD, XCU,
XCURSES, XNS, XSH, SVID2, SVID3 - Support for industry standards
DESCRIPTION
Programming interfaces and utilities conform to a number of standards.
The full names and mnemonics for the industry standards supported by
the operating system software, along with the manuals where each stan‐
dard is discussed, are as follows:
IEEE Std 1003.1: 1990 POSIX.1 Conformance Document (not included in the
Tru64 UNIX documentation set, but available by special order), Program‐
mer's Guide IEEE Std 1003.2: 1993 POSIX.2 Conformance Document (not
included in the Tru64 UNIX documentation set, but available by special
order) IEEE Std 1003.1b: 1993 POSIX.1 Conformance Document, Guide to
Realtime Programming IEEE Std 1003.1c: 1995 POSIX.1 Conformance Docu‐
ment, Guide to DECthreads ISO/IEC 9899: 1990, 1994 Programmer's Guide
X/Open CAE specifications, Issue 4, July 1992
These specifications include:
XBD, X/Open CAE Specification, System Interface Definitions,
Issue 4 (XBD4.0)
XCU, X/Open CAE Specification, Commands and Utilities, Issue 4
(XCU4.0)
XSH, X/Open CAE Specification, System Interfaces and Headers,
Issue 4 (XSH4.0) XPG4 Conformance Statement - Questionnaire (not
included in the Tru64 UNIX documentation set, but available by
special order), Programmer's Guide X/Open CAE specifications
XBD, XCU, and XSH, Issue 4, Version 2, 1994 (XBD4.2, XCU4.2, and
XSH4.2)
X/Open CAE Specification, Networking Services, Issue 4, 1994
(XNS4.0)
X/Open CAE Specification, X/Open Curses, Issue 4, 1995
(XCURSES4.0) XPG4 Conformance Statement - Questionnaire (not
included in the Tru64 UNIX documentation set, but available on
request), Programmer's Guide X/Open CAE specifications XBD, XCU,
and XSH, Issue 5, 1997 (XBD5.0, XCU5.0, and XSH5.0)
X/Open CAE Specification, Networking Services, Issue 5, 1997
(XNS5.0)
X/Open CAE Specification, X/Open Curses, Issue 4, Version 2,
1997 (XCURSES4.2)
Reference pages for individual interfaces state the current con‐
formance level to the XBD, XCU, XCURSES, XNS, or XSH CAE speci‐
fication. FIPS 151-2 POSIX.1 Conformance Document, Programmer's
Guide System V Interface Definition, Issue 2 Programmer's Guide
System V Interface Definition, Issue 3 Programmer's Guide
STANDARDS INFORMATION IN REFERENCE PAGES
Reference pages may include a STANDARDS section that specifies the most
current standards that the interfaces conform to. Header files usually
support definition environments for different issues of the UNIX speci‐
fications but the reference pages describe interfaces mostly in the
context of the most recent one. The following conventions may also be
used in the text of reference pages when it is necessary to identify
different versions of interfaces or to note interface extensions: Text
paragraphs preceded by [XPG4-UNIX] document features and behavior that
are included in the set of UNIX extensions specified by the X/Open CAE
specifications listed earlier for the XPG4-UNIX mnemonic.
The [XPG4-UNIX] tag appears only when it is necessary to differ‐
entiate an XPG4-UNIX extension that was added to an interface
that is also defined in Issue 4, Version 1 of the X/Open CAE
specifications. If an entire interface has been added in Issue
4, Version 2, the tag is not necessary. In this case, the STAN‐
DARDS section lists XPG4-UNIX, and not XPG4, as the X/Open stan‐
dard to which the interface conforms.
The [XPG4-UNIX] tag is obsolete and being replaced by tags for
particular specifications ([XSHn], [XCUn], [XNSn], or [XCURSESn]
as described below).
Whether any of these tags appears depends on the interfaces that
a reference page describes, the highest specification version to
which the interfaces conform, and whether the reference page
needs to point out a difference in an older version of an inter‐
face as compared to the most recent version. Text paragraphs
preceded by [ISO C] document features and behavior that are
included in versions and amendments to the ISO/IEC standard for
the C programming language with which the current X/Open speci‐
fications are not yet aligned. The [ISO C] tag appears only
when an interface conforms to the current XSH CAE specification
and also conforms to an ISO/IEC amendment or version that was
approved after the release of the current XSH specification. C
language extensions that fall into this category are automati‐
cally part of the next issue or revision of the XSH CAE specifi‐
cation. The [ISO C] tag does not appear when an interface
conforms to the version of the ISO/IEC standard that was
approved before the current version of the X/Open standard was
issued. By definition, X/Open specifications cannot conflict
with any ISO/IEC standard. Therefore, on most reference pages
that document an interface conforming to ISO C, you will not
find the [ISO C] tag or see a reference to ISO C in the STAN‐
DARDS section. Text paragraphs preceded by [POSIX] document
features and behavior that are included in recently approved
sections of the relevant POSIX standard.
The [POSIX] tag appears only when an interface conforms to the
most current X/Open specification and also conforms to a version
of POSIX that was finalized after release of the X/Open specifi‐
cation. The new POSIX section will automatically become part of
the next issue of the X/Open specification. By definition,
X/Open specifications cannot conflict with the POSIX standard.
Therefore, on most reference pages that document an interface
that conforms to the POSIX standard, you will not find the
[POSIX] tag or see POSIX mentioned specifically in the STAN‐
DARDS section. Text paragraphs preceded by [Tru64 UNIX] docu‐
ment features that are included in the operating system software
but are not currently specified by any standard that applies to
the interface being described. Use these features when source
code portability across multiple UNIX platforms is less impor‐
tant than the capabilities that the features provide.
The [Tru64 UNIX] tag appears only when it is necessary to flag
proprietary information on reference pages that also discuss
interfaces that conform to a standard. For example, if an
interface on the reference page returns an errno value in addi‐
tion to those specified by the applicable standards, the text
describing that errno value is flagged using the [Tru64
UNIX] tag. When an interface in its entirety is not defined by
any standard, it is omitted from the function and standards list
in the STANDARDS section of the reference page. Text paragraphs
that refer to libsys5 describe versions of interfaces that
either conflict with X/Open standards or are extensions to these
standards. Use descriptions provided for libsys5 when confor‐
mance to the AT&T System V Interface Definition (SVID2 or SVID3)
is an application requirement. Text paragraphs that begin with
explicit references to backward compatibility refer to features
or behaviors that conflict with the applicable standards. Such
syntax and behavior may be enabled, for example, when an appli‐
cation is compiled using the -std0 or -std flag. The description
of backward-compatible syntax or behavior is included to help
programmers make minor changes to existing applications and may
also be useful to programmers who are rewriting applications to
conform to X/Open UNIX specifications.
APPLICATION CONTROL OF INTERFACE DEFINITIONS
By default, the cc and c89 commands provide definition environments for
interfaces that conform to different versions of industry standards, as
well as interfaces that are completely or partially proprietary. This
section describes how application programmers can use the C compiler to
more rigorously control definition environments and their function pro‐
totypes. For complete information on using the cc and c89 commands,
refer to the cc(1) and c89(1) reference pages.
The following examples show sections of alternative C compiler command
lines that not only specify strict conformance to a specific industry
standard but also eliminate interface prototypes not included in the
definition environment for that standard. When application programmers
use the flags and arguments shown in these examples, program flexibil‐
ity (in terms of the number of valid interfaces and the prototypes for
these interfaces) is reduced to improve the portability of applications
across platforms that conform to the standard.
ISO C and ANSI C:
c89 -D _ANSI_C_SOURCE -isoc94 ... cc -std1-D_ANSI_C_SOURCE-isoc94
...
POSIX:
c89 -D _POSIX_SOURCE ... cc -std1 -D_POSIX_SOURCE ...
XPG4:
c89 -D _XOPEN_SOURCE ... cc -std1 -D_XOPEN_SOURCE ...
Single UNIX Specification (1995):
c89 -D _XOPEN_SOURCE_EXTENDED ... cc -std1 -D_XOPEN_SOURCE_EXTENDED
...
Single UNIX Specification (1998):
c89 -D _XOPEN_SOURCE=500 ... cc -std1 -D_XOPEN_SOURCE=500 ...
Notes
The cc utility is defined as a LEGACY interface in XCU5.0.
The -isoc94 compiler flag enables access to features of the ISO C 1994
amendment that conflict with XSH4.0 and XSH4.2. This flag supplements
the operations of the -std1 flag in the _XOPEN_SOURCE and
_XOPEN_SOURCE_EXTENDED definition environments. XSH5.0 aligns with
changes to the ISO C standard, so new functions defined by ISO C 1994
are part of the _ANSI_C_SOURCE environment that is subordinate to
_XOPEN_SOURCE=500. Therefore, function prototypes as revised by ISO C
1994 can be specified by using only the -std1 compiler flag when the
definition environment is specified as _XOPEN_SOURCE=500.
The following sections discuss control of definition environments and
function prototype definitions.
Controlling Definition Environments in Header Files
The -D option's arguments control the different compiler definition
environments supported by the header files that are supplied by the
operating system.
When no compilation definition macros are explicitly defined, the
default action for both the cc and c89 compilers is to include the fol‐
lowing macros: _XOPEN_SOURCE, which includes interfaces defined in Ver‐
sion 4 of The Open Group's XBD, XCU, and XSH CAE specifications
_OSF_SOURCE, which includes interface prototypes that are proprietary
The _XOPEN_SOURCE macro does not correspond to the current versions of
the Open Group's CAE specifications. In other words, you must explic‐
itly specify _XOPEN_SOURCE=500 if you are using functions as defined in
the XSH5 CAE specification (which is recommended) or _XOPEN_SOURCE=420
if you are using functions as defined in the XSH4.2 CAE specification.
(Note that _XOPEN_SOURCE is equivalent to _XOPEN_SOURCE=400 and
_XOPEN_SOURCE_EXTENDED is equivalent to _XOPEN_SOURCE=420.)
The _OSF_SOURCE macro includes proprietary definitions for interfaces.
Proprietary definitions include those for: Interfaces not included in
an industry standard at all Macro definitions that provide some perfor‐
mance improvements over the function counterparts defined in a standard
Different prototypes for interfaces that are also included in a stan‐
dard
These are provided only for backward compatibility with applica‐
tions written to use the older prototype before the standard-
conforming version was available. In this case, if the function
is also included in the ANSI C standard, you must specify the
-std0 option on the compiler command line to ensure that the
obsolete form of the function continues to work when the appli‐
cation is recompiled.
If you explicitly specify a definition environment macro, the c89 and
cc compilers include only the macros you explicitly specify. For exam‐
ple, if you specify _OSF_SOURCE=500 to override _XOPEN_SOURCE, the com‐
pilers omit _OSF_SOURCE as well. So, if you explicitly specify a defi‐
nition environment for an industry standard and your program source
code also uses proprietary interfaces, you must remember to specify
_OSF_SOURCE to access the prototypes for the proprietary interfaces.
If application portability to other platforms is a priority, do not
write source code that depends on function prototypes or macros defined
only for the _OSF_SOURCE compilation environment. For new applications,
it is recommended that you use functions as defined by the most current
versions of industry standards. This means specifying macros for cur‐
rent industry-standard compilation environments and, as explained in
the next section, using the -std1 option to ensure that the most up-to-
date versions of those interfaces are used.
Controlling Function Prototypes
While the -D flag controls which functions are declared in the header
files included by an application, the -std0, -std, and -std1 flags con‐
trol the content of prototypes for those functions included in the ANSI
C standard. For strict ISO C and ANSI C conformance, the compiler com‐
mand line must include the -std1 flag.
The c89 command includes the -std1 flag by default; however, the cc
command includes the -std flag by default. Therefore, when application
programmers use the cc command to compile applications that must
strictly conform to most industry standards, they must specify -std1
explicitly. In this case, the -std0 or the -std flags are inappropriate
because they can enable versions of syntax and behavior that either
conflict with or do not strictly conform to the ANSI C standard. Both
the POSIX and X/Open standards require strict conformance to the ANSI C
standard. Use the -std0 option only when needed to recompile an old
application whose source code you do not want to modify.
SEE ALSO
POSIX.1 Conformance Document
POSIX.2 Conformance Document
Standard for Information Technology-Portable Operating System Interface
(POSIX)-Part 1: System Application Interface (API) [C Language], Insti‐
tute of Electrical and Electronics Engineers, Inc., 1990, 1994
Standard for Information Technology-Portable Operating System Interface
(POSIX)-Part 2: Shell and Utilities, Institute of Electrical and Elec‐
tronics Engineers, Inc., 1993
X/Open Conformance Statement - Questionnaire
X/Open CAE Specification, System Interface Definitions, Issue 4, July
1992, X/Open Company Limited
X/Open CAE Specification, System Interface Definitions, Issue 4, Ver‐
sion 2, August 1994, X/Open Company Limited
X/Open CAE Specification, System Interface Definitions, Issue 5, Janu‐
ary 1997, The Open Group
X/Open CAE Specification, Commands and Utilities, Issue 4, July 1992,
X/Open Company Limited
X/Open CAE Specification, Commands and Utilities, Issue 4, Version 2,
August 1994, X/Open Company Limited
X/Open CAE Specification, Commands and Utilities, Issue 5, January
1997, The Open Group
X/Open CAE Specification, System Interfaces and Headers, Issue 4, July
1992, X/Open Company Limited
X/Open CAE Specification, System Interfaces and Headers, Issue 4, Ver‐
sion 2, August 1994, X/Open Company Limited
X/Open CAE Specification, System Interfaces and Headers, Issue 5, Janu‐
ary 1997, The Open Group
X/Open CAE Specification, Networking Services, Issue 4, September 1994,
X/Open Company Limited
X/Open CAE Specification, Networking Services, Issue 5, February 1997,
The Open Group
X/Open CAE Specification, X/Open Curses, Issue 4, January 1995, X/Open
Company Limited
X/Open CAE Specification, X/Open Curses, Issue 4. Version 2, July 1996,
X/Open Company Limited
Federal Register, Volume 55, Number 60, NIST, U.S. Government, March
28, 1990
System V Interface Definition, Issue 2, AT&T, 1986
System V Interface Definition, Issue 3, AT&T, 1989
standards(5)