[ksh93-integration-discuss] Re: Planning the final ARC case forthe first ksh93-integration putback...

[Don Cragun]

>Date: Tue, 14 Nov 2006 12:41:59 -0500 (EST)
>From: Glenn Fowler <gsf at research.att.com>
>
>the following pertains to solaris 10 -- don't know about other versions
>
>can someone explain how
>	sysconf(_SC_PASS_MAX) == 256
>for these compile options
>	cc
>	cc -D_POSIX_SOURCE=1
>	cc -D_POSIX_C_SOURCE=21000101L
>	cc -D_POSIX_SOURCE=1 -D_POSIX_C_SOURCE=21000101L
>	cc -D_XOPEN_SOURCE -D_XOPEN_VERSION=4  <<< "XPG4"
>vs.
>	/usr/bin/getconf PASS_MAX ==      256
>	/usr/xpg4/bin/getconf PASS_MAX ==   8  <<< value in question
>	/usr/xpg6/bin/getconf PASS_MAX == 256
>
>when the getconf(1) standard text specifies
>
>  The value of each configuration variable shall be determined as if it
>  were obtained by calling the function from which it is defined to be
>  available by this volume of IEEE Std 1003.1-2001 or by the System
>  Interfaces volume of IEEE Std 1003.1-2001 (see the OPERANDS section).
>  The value shall reflect conditions in the current operating
>  environment.
>
>where I assume that this is the function call for PASS_MAX:
>	sysconf(_SC_PASS_MAX)
>
>does this fall into the "shall reflect conditions in the current
>operating environment" hole?

Glenn,
	Yes.  The original X/Open Portability Guide through X/Open
Portability Guide Issue 3 (XPG3) required that <limits.h> define
PASS_MAX to be 8.  XPG4 and XPG4v2 (AKA the original The Single UNIX
Specification (AKA SUS)) still required that value, but marked PASS_MAX
"TO BE WITHDRAWN".  (The TO BE WITHDRAWN marking is very similar to the
Obsolescent marking in POSIX standards.)  The requirement to define
PASS_MAX disappeared in SUSv2.  Therefore, when an application builds
itself in XPG3, XPG4, or SUS mode; <limits.h> #defines PASS_MAX to be 8
as required by XPG3, XPG4, and SUS.

	Don
 
>
>-- Glenn Fowler -- AT&T Research, Florham Park NJ --