Content-type: text/html Man page of standards

standards

Section: File Formats (5)
Index Return to Main Contents
 

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:

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 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, Issue 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 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
X/Open CAE Specification, Networking Services, Issue 4, 1994
X/Open CAE Specification, X/Open Curses, Issue 4, 1995 XPG4 Conformance Statement - Questionnaire (not included in the Tru64 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 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 one of the standards to which the interface conforms. 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. 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. 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. 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. 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. 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]. 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 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


 

Index

NAME
DESCRIPTION
STANDARDS INFORMATION IN REFERENCE PAGES
APPLICATION CONTROL OF INTERFACE DEFINITIONS
Controlling Definition Environments in Header Files
Controlling Function Prototypes
SEE ALSO

This document was created by man2html, using the manual pages.
Time: 02:43:11 GMT, October 02, 2010