standards(5) File Formats Manual 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 standard 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), Pro-
grammer's Guide IEEE Std 1003.2: 1993 POSIX.2 Conformance Document (not included in the Tru64 UNIX documentation set, but available by spe-
cial order) IEEE Std 1003.1b: 1993 POSIX.1 Conformance Document, Guide to Realtime Programming IEEE Std 1003.1c: 1995 POSIX.1 Conformance
Document, 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 conformance level to the XBD, XCU, XCURSES, XNS, or XSH CAE specifica-
tion. 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 usu-
ally support definition environments for different issues of the UNIX specifications 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 iden-
tify different versions of interfaces or to note interface extensions: Text paragraphs preceded by [XPG4-UNIX] document features and behav-
ior 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 differentiate 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 STANDARDS section lists XPG4-UNIX, and not XPG4, as the X/Open standard 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 interface as
compared to the most recent version. Text paragraphs preceded by [ISO C] document features and behavior that are included in ver-
sions and amendments to the ISO/IEC standard for the C programming language with which the current X/Open specifications 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 automatically part of the next issue or revision of the XSH CAE specification. 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 specification. 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 STANDARDS section. Text paragraphs preceded by [Tru64 UNIX] document 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 important 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 inter-
faces that conform to a standard. For example, if an interface on the reference page returns an errno value in addition to those
specified by the applicable standards, the text describing that errno value is flagged using the [Tru64 UNIX] tag. When an inter-
face 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 stan-
dards or are extensions to these standards. Use descriptions provided for libsys5 when conformance to the AT&T System V Interface
Definition (SVID2 or SVID3) is an application requirement. Text paragraphs that begin with explicit references to backward compati-
bility refer to features or behaviors that conflict with the applicable standards. Such syntax and behavior may be enabled, for
example, when an application 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 stan-
dards, 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 prototypes. 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 indus-
try standard but also eliminate interface prototypes not included in the definition environment for that standard. When application pro-
grammers use the flags and arguments shown in these examples, program flexibility (in terms of the number of valid interfaces and the pro-
totypes 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 supple-
ments 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 Version 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
explicitly 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 performance improvements over the function counterparts defined in a
standard Different prototypes for interfaces that are also included in a standard
These are provided only for backward compatibility with applications written to use the older prototype before the standard-conform-
ing 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 application is recompiled.
If you explicitly specify a definition environment macro, the c89 and cc compilers include only the macros you explicitly specify. For
example, if you specify _OSF_SOURCE=500 to override _XOPEN_SOURCE, the compilers omit _OSF_SOURCE as well. So, if you explicitly specify a
definition 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 current 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
control the content of prototypes for those functions included in the ANSI C standard. For strict ISO C and ANSI C conformance, the com-
piler command 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],
Institute 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
Electronics 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, Version 2, August 1994, X/Open Company Limited
X/Open CAE Specification, System Interface Definitions, Issue 5, January 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, Version 2, August 1994, X/Open Company Limited
X/Open CAE Specification, System Interfaces and Headers, Issue 5, January 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)