 |
Index for
Section 5 |
|
 |
Alphabetical
listing for S |
|
 |
Bottom of
page |
|
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:
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, Guide to Realtime Programming
POSIX.1c
IEEE Std 1003.1c: 1995
References:
POSIX.1 Conformance Document, Guide to DECthreads
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
(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)
References:
XPG4 Conformance Statement - Questionnaire (not included in the
Tru64 UNIX documentation set, but available by special order),
Programmer's Guide
XPG4-UNIX (Single UNIX Specification, 1995)
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)
References:
XPG4 Conformance Statement - Questionnaire (not included in the
Tru64 UNIX documentation set, but available on request),
Programmer's Guide
Single UNIX Specification, 1998
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
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 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:
[X...]
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.
[ISO C]
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.
[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 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.
[Tru64 UNIX]
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.
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
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
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
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.
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
|
Index for
Section 5 |
|
|
Alphabetical
listing for S |
|
 |
Top of
page |
|