WG15 Defect Report Ref: 9945-1-27
Topic: _POSIX_VDISABLE symbol


This is an approved interpretation of 9945-1:1990.

.

Last update: 1997-05-20


                                                                9945-1-90 #27

        Classification: Editorial defect
 _____________________________________________________________________________



	Topic:			_POSIX_VDISABLE symbol
	Relevant Sections:	2.9.4


Defect Report:
-----------------------


A question has been raised with regard to the
requirements POSIX.1 places on the form of the
value defined for the _POSIX_VDISABLE symbol.
Does the Standard require that _POSIX_VDISABLE be
a preprocessor number?  For example, an
implementation might use the value (unsigned
char)255, which the C preprocessor won't compare
to -1.

_POSIX_VDISABLE is listed as an "Execution-Time
Symbolic Constant".  Must it also be usable in
numerical comparisons in the preprocessor? The
constants that are guaranteed to be usable at
compile time are listed separately, as "Compile-
Time Symbolic Constants".

My reading is that though it would be nice if one
could use this value at compile time, and though
the authors might have intended that it be usable
this way, the standard does not guarantee it.

From POSIX.1 (2.9.4, page 38, lines 1129 ff.):

   The constants in Table 2-11 may be used by the
   application, at execution time, to determine
   which optional facilities are present and what
   actions shall be taken by the implementation
   ...

Under the implementation example described above,
the proper way to use a constant from table 2.11
is to use #ifdef to see whether it's defined in
<unistd.h>, but to do a numerical comparison only
at run time.


WG15 response for ISO/IEC 9945-1:1990 (IEEE Std 1003.1-1990)
--------------------------------------------------


	The standard does not require that _POSIX_VDISABLE be a
	preprocessor number.  The standard does not require that
	_POSIX_VDISABLE be usable in numeric comparisons in the
	preprocessor.



Rationale for Interpretation:
-----------------------------

The standard makes no requirement that the constant _POSIX_VDISABLE be a
preprocessor number.  The requirements relating this constant in section
2.9.4 relate only to use at execution time.

It is understandable why an application might like to be able to use
_POSIX_VDISABLE as a preprocessor constant.  The wording in section
2.9.4:

	If any of the constants in Table 2-11 are defined to have
	value -1 in the header ....

can suggest, on casual reading, code like the following to minimize size
and optimize efficiency for each implementation:

	#ifdef _POSIX_VDISABLE
	#if    _POSIX_VDISABLE == -1
	    /* code that assumes no vdisable capability */
	#else
	    /* code that assumes vdisable capability */
	#endif
	#else
	    /* code that uses pathconf() to determine vdisable capability */
	#endif

However, there is no wording in the standard to actually back up that
suggestion, and silence on the part of the standard means no
requirement.

There are reasons why an implementor might want to define a value that
is not a preprocessor number, such as including a type cast to avoid
problems in comparing the value to a member of the c_cc array member of
a termios struct (which is constrained by the standard to be an unsigned
integer type).  Since no wording in the standard prohibits this, it is
implicitly permitted.

Thus, rather than the above fragment, an implementation could include
code like:

	#ifdef _POSIX_VDISABLE
	    if (_POSIX_VDISABLE == -1) {
		/* code that assumes no vdisable capability */
	    } else {
		/* code that assumes vdisable capability */
	    }
	#else
	    /* code that uses pathconf() to determine vdisable capability */
	#endif

Of course it is generally simplest, though potentially less efficient,
to just write the code that uses pathconf().
 _____________________________________________________________________________