*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> SVID3 (5)              
Title
Content
Arch
Section
 

standards(5)

Contents


NAME    [Toc]    [Back]

       standards,  ANSI, ISO, OSF_SOURCE, POSIX, XPG4, XPG4-UNIX,
       XBD, XCU, XCURSES, XNS, XSH, SVID2, SVID3  -  Support  for
       industry standards

DESCRIPTION    [Toc]    [Back]

       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:

       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,
 Guide to Realtime Programming IEEE Std 1003.1c: 1995
       POSIX.1 Conformance Document, Guide to DECthreads  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 (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)  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
              (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)  XPG4  Conformance  Statement  -
              Questionnaire (not included in the Tru64 UNIX documentation
 set, but available on request),  Programmer's
 Guide 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 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    [Toc]    [Back]

       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: 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.
              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.  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.  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.  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 backwardcompatible
 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    [Toc]    [Back]

       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    [Toc]    [Back]
       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    [Toc]    [Back]
       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    [Toc]    [Back]

      
      
       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



                                                     standards(5)
[ Back ]
 Similar pages
Name OS Title
unicode Tru64 Support for the Unicode and ISO/IEC 10646 standards
universal.utf8 Tru64 Support for the Unicode and ISO/IEC 10646 standards
UCS-4 Tru64 Support for the Unicode and ISO/IEC 10646 standards
UTF-8 Tru64 Support for the Unicode and ISO/IEC 10646 standards
iso10646 Tru64 Support for the Unicode and ISO/IEC 10646 standards
Unicode Tru64 Support for the Unicode and ISO/IEC 10646 standards
UTF-16 Tru64 Support for the Unicode and ISO/IEC 10646 standards
UTF-32 Tru64 Support for the Unicode and ISO/IEC 10646 standards
UCS-2 Tru64 Support for the Unicode and ISO/IEC 10646 standards
XStandards Tru64 X Consortium Standards
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service