XCURSES man page on OSF1

Printed from http://www.polarhome.com/service/man/?qf=XCURSES&af=0&tf=2&of=OSF1

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	 stan‐
       dard 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), Program‐
       mer'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	 Docu‐
       ment,  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 con‐
	      formance	level to the XBD, XCU, XCURSES, XNS, or XSH CAE speci‐
	      fication.	 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 the most
       current	standards that the interfaces conform to. Header files usually
       support definition environments for different issues of the UNIX speci‐
       fications  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 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 the X/Open stan‐
	      dard 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 inter‐
	      face  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	speci‐
	      fications	 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 automati‐
	      cally part of the next issue or revision of the XSH CAE specifi‐
	      cation.	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 STAN‐
	      DARDS 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 specifi‐
	      cation.  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	 STAN‐
	      DARDS  section.  Text paragraphs preceded by [Tru64 UNIX]	 docu‐
	      ment 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 impor‐
	      tant 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 addi‐
	      tion 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 confor‐
	      mance 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	appli‐
	      cation 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 pro‐
       totypes. 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 flexibil‐
       ity (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 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 fol‐
       lowing macros: _XOPEN_SOURCE, which includes interfaces defined in Ver‐
       sion 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  explic‐
       itly 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 perfor‐
       mance 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 applica‐
	      tions  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 appli‐
	      cation is recompiled.

       If you explicitly specify a definition environment macro, the  c89  and
       cc  compilers include only the macros you explicitly specify. For exam‐
       ple, if you specify _OSF_SOURCE=500 to override _XOPEN_SOURCE, the com‐
       pilers  omit _OSF_SOURCE as well. So, if you explicitly specify a defi‐
       nition 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  cur‐
       rent  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 con‐
       trol the content of prototypes for those functions included in the ANSI
       C standard. For strict ISO C and ANSI C conformance, the compiler  com‐
       mand 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], 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, System Interface Definitions, Issue 5,	 Janu‐
       ary 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, Ver‐
       sion 2, August 1994, X/Open Company Limited

       X/Open CAE Specification, System Interfaces and Headers, Issue 5, Janu‐
       ary 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)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server OSF1

List of man pages available for OSF1

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net