 |
Index for Section 5 |
|
 |
Alphabetical listing for S |
|
standards(5)
NAME
standards, ANSI, ISO, POSIX, XPG4, XPG4-UNIX, SVID2, SVID3 - Support for
industry standards
DESCRIPTION
The Tru64 UNIX operating system conforms to a number of standards. The
mnemonics and names for industry standards supported by the Tru64 UNIX
software, along with the Tru64 UNIX manuals where each standard is
discussed are as follows:
POSIX.1
IEEE Std 1003.1: 1990
References:
POSIX.1 Conformance Document (not included in the Tru64 UNIX
documentation set, but available by special order), Programmer's
Guide
POSIX.2
IEEE Std 1003.2: 1993
References:
POSIX.2 Conformance Document (not included in the Tru64 UNIX
documentation set, but available by special order)
POSIX.1b
IEEE Std 1003.1b: 1993
References:
POSIX.1 Conformance Document
POSIX.1c
IEEE Std 1003.1c: 1995
References:
POSIX.1 Conformance Document
ISO C
ISO/IEC 9899: 1990, 1994
References:
Programmer's Guide
XPG4
X/Open CAE specifications, Issue 4, July 1992
These specifications include:
XBD, X/Open CAE Specification, System Interface Definitions, Issue 4
XCU, X/Open CAE Specification, Commands and Utilities, Issue 4
XSH, X/Open CAE Specification, System Interfaces and Headers, Issue 4
References:
XPG4 Conformance Statement - Questionnaire (not included in the
Tru64 UNIX documentation set, but available by special order),
Programmer's Guide
XPG4-UNIX
X/Open CAE specifications XBD, XCU, and XSH, Issue 4, Version 2, 1994
X/Open CAE Specification, Networking Services, Issue 4, 1994
X/Open CAE Specification, X/Open Curses, Issue 4, 1995
References:
XPG4 Conformance Statement - Questionnaire (not included in the
Tru64 UNIX documentation set, but available on request),
Programmer's Guide
FIPS
FIPS 151-2
References:
POSIX.1 Conformance Document, Programmer's Guide
SVID 2
System V Interface Definition, Issue 2
References:
Programmer's Guide
SVID 3
System V Interface Definition, Issue 3
References:
Programmer's Guide
STANDARDS INFORMATION IN REFERENCE PAGES
Reference pages may include a STANDARDS section that specifies which
standards different interfaces conform to. 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:
[XPG4-UNIX]
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 one of the standards to which the interface conforms.
[XSHn]
Text paragraphs preceded by [XSHn]document features and behavior that
are included in Issue n of the X/Open CAE Specification, System
Interfaces and Headers. In a future release of the product, [XSHn] will
replace [XPG4-UNIX] in reference pages for appropriate programming
interfaces.
[XCUn]
Text paragraphs preceded by [XCUn]document features and behavior that
are included in Issue n of the X/Open CAE Specification, Commands and
Utilities. In a future release of the product, [XCUn] will replace
[XPG4-UNIX] in reference pages for appropriate shells and utilities.
[XNSn]
Text paragraphs preceded by [XNSn] document features and behavior that
are included in Issue n of the X/Open CAE Specification, Networking
Services. In a future release of the product, [XNSn] will replace
[XPG4-UNIX] in reference pages for appropriate programming interfaces.
[ISO C]
Text paragraphs preceded by [ISO C] document features and behavior that
are included in recently approved amendments to the ISO/IEC standard
for the C programming language. The [ISO C] tag appears only when an
interface conforms to Issue 4 of the X/Open CAE specification and also
conforms to an ISO/IEC amendment that was approved after release of the
X/Open specification. C language extensions that fall into this
category will automatically become part of Issue 5 of the X/Open
standard. The [ISO C] tag does not appear when an interface conforms to
an ISO/IEC standard as approved when 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
tag, but will see ISO C listed as one of the standards to which the
interface conforms.
[POSIX]
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 Issue 4 of
the X/Open specification and also conforms to a version of POSIX that
was finalized after release of the X/Open standard. The new POSIX
section will automatically become part of Issue 5 of the X/Open
standard. The [POSIX] tag does not appear when an interface conforms to
sections of POSIX that were approved when the X/Open standard was
issued. By definition, X/Open specifications cannot conflict with the
POSIX standard. Therefore, on most reference pages that document an
interface conforming to POSIX, you will not find the [POSIX] tag, but
will see POSIX.section listed as a standard to which the interface
conforms.
[DIGITAL], [Digital], or [Compaq]
Text paragraphs preceded by [Digital], [DIGITAL], or [Compaq] document
features that are included in the Tru64 UNIX 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.
One of these tags appears only when it is necessary to flag nonstandard
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
so you can recognize the behavior as an extension. 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.
Tag string inconsistency is a temporary condition due to recent
corporate and product name changes. In a future release, this tag will
appear as [Tru64 UNIX].
libsys5 references
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.
backward compatibility references
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 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
both standard and nonstandard interfaces. 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 definitions of any interfaces not included in
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 ...
XPG4-UNIX:
c89 -D _XOPEN_SOURCE_EXTENDED ...
cc -std1 -D_XOPEN_SOURCE_EXTENDED ...
Note
The cc command is scheduled to be withdrawn from a future issue of the
X/Open CAE specification for commands and utilities.
The -isoc94 compiler flag enables access to features of the ISO C 1994
amendment that conflict with XPG4. This flag supplements the
operations of the -std1 flag and has precedence over definition
environments specified by the -D flag. When the operating system
supports the next issue of the XSH X/Open CAE specification, which
must align with changes to the ISO C standard, new functions defined
by ISO C 94 will become part of the _ANSI_C_SOURCE environment, and
function prototypes as revised by ISO C 94 will be specified by using
the -std1 compiler flag.
The following sections discuss control of definition environments and
function prototype definitions.
Controlling Definition Environments in Header Files
The -D flag arguments can control the different definition environments
supported by the header files that are supplied by the operating system.
Some of the arguments that control these environments are hierarchically
inclusive, specifically:
· _XOPEN_SOURCE_EXTENDED includes all definitions that are included by
_XOPEN_SOURCE
· _XOPEN_SOURCE includes all definitions that are included by
_POSIX_SOURCE
· _POSIX_SOURCE includes all definitions that are included by
_ANSI_C_SOURCE
The default behavior of the c89 and cc commands differs with respect to the
_XOPEN_SOURCE_EXTENDED macro:
· If the -D flag is omitted from the c89 command line, the compiler
automatically includes all the preceding macros for standards-related
definition environments, plus additional macros that supply definition
environments for functions that Tru64 UNIX supports but that are not
defined in the ISO C, POSIX, XPG4, or XPG4-UNIX standards.
· If the -D flag is omitted from the cc command, the cc command includes
the preceding standards-related macros, except for
_XOPEN_SOURCE_EXTENDED, along with macros for the proprietary
definition environments. Programs cannot access both the
_XOPEN_SOURCE_EXTENDED definition environment and proprietary
definition environments through the cc command.
The macros that specify nonstandard, or proprietary definition environments
are undocumented because they are intended only for internal use by
compiler software; these proprietary arguments are subject to change and
are not supported for explicit use in customer applications. In terms of
customizing the definition environments in header files supplied by the
operating system, programmers should therefore use the -D flag (or
comparable defines in program source) only when they want to eliminate
interfaces defined in nonstandard environments.
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 the function prototypes, specifically, how strictly the function
prototypes conform to 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 -std0 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.
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, 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, 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, Networking Services, Issue 4, September 1994,
X/Open Company Limited
X/Open CAE Specification, X/Open Curses, Issue 4, January 1995, 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