unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Page:
Section:
Apropos / Subsearch:
optional field



standards(5)							 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 docu-
	  mentation 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 docu-
	  mentation 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 sup-
  port definition environments for different issues of the UNIX	specifica-
  tions	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 particu-
      lar 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 specifica-
      tions are	not yet	aligned. The  [ISO C]  tag appears only	when an
      interface	conforms to the	current	XSH CAE	specification and also con-
      forms 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 stan-
      dard that	was approved before the	current	version	of the X/Open stan-
      dard 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 con-
      flict 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 STAN-
      DARDS section.

  [Tru64 UNIX]
      Text paragraphs preceded by [Tru64 UNIX]	document features that are
      included in the operating	system software	but are	not currently speci-
      fied by any standard that	applies	to the interface being described. Use
      these features when source code portability across multiple UNIX plat-
      forms is less important than the capabilities that the features pro-
      vide.

      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 refer-
      ence 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 compa-
      tibility refer to	features or behaviors that conflict with the applica-
      ble 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	sec-
  tion 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	stan-
  dard 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	func-
  tion 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 operat-
  ing system.

  When no compilation definition macros	are explicitly defined,	the default
  action for both the cc and c89 compilers is to include the following mac-
  ros:

    +  _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 stan-
       dard

       These are provided only for backward compatibility with applications
       written to use the older	prototype before the standard-conforming ver-
       sion 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 contin-
       ues 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 proto-
  types	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 recom-
  mended 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	ver-
  sions	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 Electron-
  ics 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 Com-
  pany 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