*** UNIX MANUAL PAGE BROWSER ***

standards(5) File Formats Manual standards(5) NAME standards, ANSI, ISO, POSIX, XPG4, XPG4-UNIX, SVID2, SVID3 - Support for industry standards DESCRIPTION The DIGITAL UNIX Version 4.0 operating system conforms to a number of standards. The mnemonics and names for industry standards supported by the DIGITAL UNIX software, along with the DIGITAL UNIX manuals where each standard is discussed are as follows: IEEE Std 1003.1: 1990 POSIX.1 Conformance Document (not included in the DIGITAL 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 DIGITAL UNIX documentation set, but available by spe- cial order) IEEE Std 1003.1b: 1993 POSIX.1 Conformance Document IEEE Std 1003.1c: 1995 POSIX.1 Conformance Document 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, Is- sue 4 XCU, X/Open CAE Specification, Commands and Utilities, Issue 4 XSH, X/Open CAE Specification, System Interfaces and Headers, Issue 4 XPG4 Conformance Statement - Questionnaire (not included in the DIGITAL UNIX documentation set, but available by special order), Programmer's Guide 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 XPG4 Con- formance Statement - Questionnaire (not included in the DIGITAL UNIX documentation set, but available on request), Programmer's Guide 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 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 exten- sions: 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 differ- entiate 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 STAN- DARDS section lists XPG4-UNIX, and not XPG4, as one of the stan- dards to which the interface conforms. 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 in- terface 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 defin- ition, 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 in- terface conforms. 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 specifica- tions 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 con- forms. Text paragraphs preceded by [Digital] document features that are included in the DIGITAL UNIX software but are not cur- rently 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 capa- bilities that the features provide. The [Digital] tag appears only when it is necessary to flag non- standard 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 [Digital] tag. When an in- terface 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 refer- ences to backward compatibility refer to features or behaviors that conflict with the applicable standards. Such syntax and be- havior may be enabled, for example, when an application is com- piled using the -std0 or -std flag. The description of back- ward-compatible syntax or behavior is included to help program- mers 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 con- trol definition environments and their function prototypes. For com- plete 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 argu- ments 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 opera- tions 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 sys- tem. Some of the arguments that control these environments are hierar- chically 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 in- cludes 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 DIGITAL 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 defi- nition environments. Programs cannot access both the _XOPEN_SOURCE_EX- TENDED definition environment and proprietary definition environments through the cc command. The macros that specify nonstandard, or proprietary definition environ- ments 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 sup- plied 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 con- trol 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], Insti- tute 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 Elec- tronics 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, Ver- sion 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, Ver- sion 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 standards(5)