standards, ANSI, ISO, OSF_SOURCE, POSIX, XPG4, XPG4-UNIX,
XBD, XCU, XCURSES, XNS, XSH, SVID2, SVID3 - Support for
industry standards
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), Programmer'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 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 specification. 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 [Toc] [Back] 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 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 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 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 versions
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 STANDARDS 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 interfaces 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 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 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 compatibility 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 backwardcompatible
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 [Toc] [Back] 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 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 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
flexibility (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 [Toc] [Back]
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 following 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-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 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 [Toc] [Back]
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 compiler 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.
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)
[ Back ] |
