Index Index for
Section 5
Index Alphabetical
listing for S
Index 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. Note Some reference pages use [DIGITAL] or [Digital] to mark proprietary information. These reference pages will be corrected to use [Tru64 UNIX] in a future release of the operating system. 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 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=500 includes all definitions that are included by_XOPEN_SOURCE_EXTENDED · _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 When no definition macros are explicitly defined, the compiler defaults are as follows: · The c89 compiler automatically includes all the preceding macros for standards-related definition environments other than _XOPEN_SOURCE=500. The compiler also includes the _OSF_SOURCE macro, which is described next. · The cc compiler includes the preceding standards-related macros, except for _XOPEN_SOURCE=500 and _XOPEN_SOURCE_EXTENDED. The compiler also includes the _OSF_SOURCE macro, which is described next. The _OSF_SOURCE macro includes definitions for interfaces that are proprietary (not included in any definition environments that support industry standards). In some cases, the proprietary definition environment includes macro definitions that provide some performance improvements over the function prototypes required by industry standards. For a few interfaces, the _OSF_SOURCE definition environment includes non-conforming prototypes for functions with different prototypes in the definition environments for industry standards. This allows backward compatibility with applications written to use the older prototype before the standard- conforming version was available. (In the latter case, if the function is included in the ANSI C standard, the -std0 option on the compiler command line ensures that the obsolete form of the function continues to work when the application is recompiled. However, for new applications, it is strongly recommended that you use functions as defined by the most current versions of industry standards.) Both the c89 and cc commands include the _OSF_SOURCE definition environment by default. However, if you explicitly specify a definition environment for an industry standard and the application also uses proprietary interfaces, you must also explicitly specify _OSF_SOURCE to access the prototypes for those proprietary interfaces. If application portability to other platforms is a priority, do not write source code that depends on function prototypes or macros defined in header files only for the _OSF_SOURCE compilation environment. 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 function 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 Index for
Section 5
Index Alphabetical
listing for S
Index Top of
page