standards, ANSI, C, C++, ISO, POSIX, POSIX.1, POSIX.2,  SUS,
     SUSv2, SVID, SVID3, XNS, XNS4, XNS5, XPG, XPG3, XPG4, XPG4v2
     - standards and specifications supported by Solaris


     Solaris 9supports IEEE Std 1003.1 and IEEE Std 1003.2,  com-
     monly  known  as POSIX.1 and POSIX.2, respectively. The fol-
     lowing table lists each version of these  standards  with  a
     brief  description  and  the  SunOS  or Solaris release that
     first conformed to it.

     POSIX Standard             Description                  Release
     POSIX.1-1988     system interfaces and headers     SunOS 4.1
     POSIX.1-1990     POSIX.1-1988 update               Solaris 2.0
     POSIX.1b-1993    realtime extensions               Solaris 2.4
     POSIX.1c-1996    threads extensions                Solaris 2.6
     POSIX.2-1992     shell and utilities               Solaris 2.5
     POSIX.2a-1992    interactive shell and utilities   Solaris 2.5

     Solaris  9also   supports  the  X/Open  Common  Applications
     Environment (CAE) Portability Guide Issue 3 (XPG3) and Issue
     4 (XPG4), Single UNIX  Specification  (SUS,  also  known  as
     XPG4v2),  and  Single UNIX Specification, Version 2 (SUSv2).
     Both XPG4  and  SUS  include  Networking  Services  Issue  4
     (XNS4). SUSv2 includes Networking Services Issue 5 (XNS5).

     The following table lists each X/Open specification  with  a
     brief  description  and  the  SunOS  or Solaris release that
     first conformed to it.

     X/Open CAE Specification          Description                Release
     XPG3                       superset  of  POSIX.1-1988   SunOS 4.1
                                containing  utilities from
     XPG4                       superset of  POSIX.1-1990,   Solaris 2.4
                                POSIX.2-1992,          and
                                POSIX.2a-1992   containing
                                extensions  to POSIX stan-
                                dards from XPG3
     SUS (XPG4v2)               superset of XPG4  contain-   Solaris 2.6
                                ing  historical BSD inter-
                                faces widely used by  com-
                                mon application packages
     XNS4                       sockets and XTI interfaces   Solaris 2.6
     SUSv2                      superset of  SUS  extended   Solaris 7
                                to  support POSIX.1b-1993,
                                POSIX.1c-1996, and ISO/IEC
                                9899  (C  Standard) Amend-
                                ment 1

     XNS5                       superset  and   LP64-clean   Solaris 7
                                derivative of XNS4.

     The XNS4 specification is safe for use only  in  ILP32  (32-
     bit)  environments  and should not be used for LP64 (64-bit)
     application environments. Use  XNS5,  which  has  LP64-clean
     interfaces  that are portable across ILP32 and LP64 environ-
     ments. Solaris releases 7 through 9 support both  the  ILP32
     and ILP64 enviornments.

     Solaris releases 7 through 9 have been branded to conform to
     The Open Group's UNIX 98 Product Standard.

     Solaris releases 2.0 through 9 support the interfaces speci-
     fied  by  the  System V Interface Definition, Third Edition,
     Volumes 1 through 4 (SVID3).  Note, however, that since  the
     developers of this specification (UNIX Systems Laboratories)
     are no longer  in  business  and  since  this  specification
     defers to POSIX and X/Open CAE specifications, there is some
     disagreement about what is currently  required  for  confor-
     mance to this specification.

     When Sun WorkShop  Compiler  C  4.2  is  installed,  Solaris
     releases 2.0 through 9 support the ANSI X3.159-1989 Program-
     ming Language - C and ISO/IEC 9899:1990 Programming Language
     - C (C) interfaces.

     When Sun WorkShop  Compiler  C  5.0  is  installed,  Solaris
     releases  7 through 9 also support ISO/IEC 9899 Amendment 1:
     C Integrity.

     When Sun WorkShop Compiler C++  5.0  is  installed,  Solaris
     releases 2.5.1 through 9 support ISO/IEC 14882:1998 Program-
     ming Languages - C++.  Unsupported features of that standard
     are  described in the compiler README file.  The features of
     the C++ standard adopted from ISO/IEC 9899 Amendement 1  are
     not  supported on Solaris 2.5.1, and are only partially sup-
     ported on Solaris 2.6.

     If the behavior required by POSIX.2, POSIX.2a, XPG4, SUS, or
     SUSv2  conflicts  with  historical Solaris utility behavior,
     the original Solaris version of the utility is unchanged;  a
     new version that is standard-conforming has been provided in
     /usr/xpg4/bin. For applications wishing to take advantage of
     POSIX.2,  POSIX.2a,  XPG4,  SUS, or SUSv2 features, the PATH
     (sh or ksh) or path (csh) environment  variables  should  be
     set  with  /usr/xpg4/bin  preceding any other directories in
     which  utilities   specified  by  those  specifications  are
     found, such as /bin, /usr/bin, /usr/ucb, and /usr/ccs/bin.

  Feature Test Macros
     Feature test macros are used  by  applications  to  indicate
     additional  sets  of  features that are desired beyond those
     specified by the C standard. If  an  application  uses  only
     those  interfaces  and headers defined by a particular stan-
     dard (such as POSIX or  X/Open  CAE),   then  it  need  only
     define  the appropriate feature test macro specified by that
     standard. If the application is using interfaces and headers
     not  defined  by that standard, then in addition to defining
     the appropriate standard feature test macro,  it  must  also
     define  __EXTENSIONS__. Defining __EXTENSIONS__ provides the
     application with access to all interfaces and headers not in
     conflict  with  the specified standard. The application must
     define __EXTENSIONS__ either at compile time or  within  the
     applicatio'n source files.

     No feature test macros need to be defined to  indicate  that
     an application is a conforming C application.

     ANSI/ISO C++ does not define any feature test macros. If the
     standard C++ announcement macro __cplusplus is predefined to
     value  199711  or  greater,  the  compiler  operates  in   a
     standard-conforming  mode,  indicating C++ standards confor-
     mance. The value 199711  indicates  conformance  to  ISO/IEC
     14882:1998,  as required by that standard.  (As noted above,
     conformance to the standard  is  incomplete.)   A  standard-
     conforming mode is not available with compilers prior to Sun
     WorkShop C++ 5.0.

     C++ bindings are not defined for POSIX  or  X/Open  CAE,  so
     specifying  feature  test  macros  such as _POSIX_SOURCE and
     _XOPEN_SOURCE can result in compilation errors due  to  con-
     flicting  requirements  of standard C++ and those specifica-

     Applications that are  intended  to  be  conforming  POSIX.1
     applications  must  define the feature test macros specified
     by the standard before including any headers.  For the stan-
     dards  listed  below,  applications  must define the feature
     test macros listed.   Application  writers  must  check  the
     corresponding standards for other macros that can be queried
     to determine if desired options are supported by the  imple-

           POSIX Standard                  Feature Test Macros
     POSIX.1-1990                  _POSIX_SOURCE

     POSIX.1-1990 and              _POSIX_SOURCE and _POSIX_C_SOURCE=2
       Bindings Option
     POSIX.1b-1993                 _POSIX_C_SOURCE=199309L
     POSIX.1c-1996                 _POSIX_C_SOURCE=199506L

     The SVID3 specification does not specify  any  feature  test
     macros  to  indicate  that an application is written to meet
     SVID3 requirements.  The  SVID3  specification  was  written
     before the C standard was completed.

  X/Open CAE
     To build or compile an application that conforms to  one  of
     the X/Open CAE specifications, use the following guidelines.
     Applications need not set the POSIX feature test  macros  if
     they require both CAE and POSIX functionality.

     XPG3  The application must define _XOPEN_SOURCE with a value
           other than 500 (preferably 1).

     XPG4  The application must define _XOPEN_SOURCE with a value
           other    than    500    (preferably    1)    and   set

     SUS (XPG4v2)
           The application must define _XOPEN_SOURCE with a value
           other    than    500    (preferably    1)    and   set

     SUSv2 The application must define _XOPEN_SOURCE=500.

     A POSIX.2-, XPG4-, SUS-, or SUSv2-conforming  implementation
     must   include   an   ANSI  X3.159-1989  (ANSI  C  Language)
     standard-conforming compilation system and the  cc  and  c89
     utilities.  Solaris  7 through 9 were tested with the cc and
     c89 utilities and the compilation  system  provided  by  Sun
     WorkShop  Compiler  C 5.0 in the SPARC and x86 environments.
     When cc is used to link  applications,  /usr/ccs/lib/values-
     xpg4.o  must be specified on any link/load command line, but
     the preferred way to build applications is described below.

     An XNS4- or XNS5-conforming application must include -l  XNS
     on  any  link/load  command line in addition to defining the
     feature test macros specified  for  SUS  or  SUSv2,  respec-

     If  the  compiler  suppports  the  redefine_extname   pragma
     feature  (the  Sun  WorkShop Compiler C 4.2 and Sun WorkShop
     Compiler    C    5.0    compilers    define    the     macro
     __PRAGMA_REDEFINE_EXTNAME  to indicate that it supports this
     feature),   then   the   standard   headers   use    #pragma
     redefine_extname  directives  to properly map function names
     onto library entry point names. This mapping  provides  full
     support for ISO C, POSIX, and X/Open namespace reservations.
     The Sun WorkShop  Compiler C 5.0 compiler was used  for  all
     branding  and  certification  tests  for  Solaris releases 7
     through 9.

     If this pragma feature is not supported by the compiler, the
     headers  use  the #define directive to map internal function
     names onto appropriate library entry point  names.  In  this
     instance,  applications  should avoid using the explicit 64-
     bit file offset symbols listed on the lf64(5)  manual  page,
     since these names are used by the implementation to name the
     alternative entry points.

     When using Sun WorkShop Compiler C  5.0,  applications  con-
     forming  to  the  specifications listed above should be com-
     piled using the utilities and flags indicated in the follow-
     ing table:

         Specification       Compiler/Flags        Feature Test Macros
     ANSI/ISO C              c89              none
     SVID3                   cc -Xt           none
     POSIX.1-1990            c89              _POSIX_SOURCE
     POSIX.1-1990 and        c89              _POSIX_SOURCE  and
       POSIX.2-1992                             POSIX_C_SOURCE=2
       Bindings Option
     POSIX.1b-1993           c89              _POSIX_C_SOURCE=199309L
     POSIX.1c-1996           c89              _POSIX_C_SOURCE=199506L
     CAE XPG3                cc -Xa           _XOPEN_SOURCE
     CAE XPG4                c89              _XOPEN_SOURCE and
     SUS (CAE XPG4v2)        c89              _XOPEN_SOURCE and
       (includes XNS4)                          _XOPEN_SOURCE_EXTENDED=1
     SUSv2 (includes XNS5)   c89              _XOPEN_SOURCE=500

     For  platforms  supporting  the  LP64  (64-bit)  programming
     environment  where  the SC5.0 Compilers have been installed,
     SUSv2-conforming LP64 applications using XNS5 library  calls
     should be built with command lines of the form:

     c89 $(getconf XBS5_LP64_OFF64_CFLAGS) -D_XOPEN_SOURCE=500 \
         $(getconf XBS5_LP64_OFF64_LDFLAGS) foo.c -o foo \
         $(getconf XBS5_LP64_OFF64_LIBS) -lxnet


     sysconf(3C), environ(5), lf64(5)

Man(1) output converted with man2html