Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
standards(5)	      Standards, Environments, and Macros	  standards(5)

NAME
       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

DESCRIPTION
       Solaris	9supports  IEEE	Std 1003.1 and IEEE Std	1003.2,	commonly known
       as POSIX.1 and POSIX.2, respectively. The following  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  Specifica-
       tion,  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
				  SVID3
       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)  environ-
       ments  and  should  not	be used	for LP64 (64-bit) application environ-
       ments. Use XNS5,	which has  LP64-clean  interfaces  that	 are  portable
       across  ILP32  and LP64 environments. Solaris releases 7	through	9 sup-
       port 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 specified	by the
       System V	Interface Definition,  Third  Edition,	Volumes	 1  through  4
       (SVID3).	  Note,	 however, that since the developers of this specifica-
       tion (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  conformance
       to this specification.

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

       When  Sun  WorkShop  Compilertm	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	 Programming  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 par-
       tially supported	on Solaris 2.6.

   Utilities
       If the behavior required	by POSIX.2, POSIX.2a, XPG4, SUS, or SUSv2 con-
       flicts 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 stan-
       dard.  If an application	uses only those	interfaces and headers defined
       by a particular standard	(such as POSIX or X/Open CAE),	then  it  need
       only  define the	appropriate feature test macro specified by that stan-
       dard. 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  applica-
       tion  must  define __EXTENSIONS__ either	at compile time	or  within the
       applicatio'n source files.

   ANSI/ISO C
       No feature test macros need to be defined to indicate that an  applica-
       tion is a conforming C application.

   ANSI/ISO C++
       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, indicat-
       ing C++ standards conformance. 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 conflicting requirements of standard C++
       and those specifications.

   POSIX
       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 standards  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 implementation.

	     POSIX Standard		     Feature Test Macros
       POSIX.1-1990		     _POSIX_SOURCE
       POSIX.1-1990 and		     _POSIX_SOURCE and _POSIX_C_SOURCE=2
	 POSIX.2-1992
	 C-Language
	 Bindings Option
       POSIX.1b-1993		     _POSIX_C_SOURCE=199309L
       POSIX.1c-1996		     _POSIX_C_SOURCE=199506L

   SVID3
       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 com-
       pleted.

   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	_XOPEN_VERSION=4.

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

       SUSv2 The application must define _XOPEN_SOURCE=500.

   Compilation
       A  POSIX.2-,  XPG4-,  SUS-,  or	SUSv2-conforming  implementation  must
       include	an ANSI	X3.159-1989 (ANSI C Language) standard-conforming com-
       pilation	system and the cc and c89 utilities. Solaris 7 through 9  were
       tested  with  the  cc and c89 utilities and the compilation system pro-
       vided by	Sun WorkShop Compilertm	C 5.0 in the  SPARC  and  IA  environ-
       ments. 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, respectively.

       If  the compiler	suppports the redefine_extname pragma feature (the Sun
       WorkShop	Compilertm C 4.2 and Sun WorkShop Compilertm 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  Compilertm	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 appropri-
       ate  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 Compilertm C 5.0,  applications	conforming  to
       the  specifications listed above	should be compiled using the utilities
       and flags indicated in the following 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
	 C-Language
	 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
						  _XOPEN_VERSION=4
       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

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

SunOS 5.9			  29 Aug 2001			  standards(5)

NAME | DESCRIPTION | SEE ALSO

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=XPG4&sektion=5&manpath=SunOS+5.9>

home | help