Some questions about POSIX headers

[Jeffrey Kegler]

From: jeffrey at algor2.algorists.com (Jeffrey Kegler)

In article <6649 at portia.Stanford.EDU> karish at forel.stanford.edu (Chuck Karish) writes:

>According to Section 2.8.2.1 of the 1003.1 document, "If there are no
>feature test macros present in a program, only the set of symbols
>defined by the C standard shall be present".  This means that the
>symbols may be present, but they must be concealed by a feature test
>macro:

>#ifdef	_C_LIBRARY
>#define _LOW(__v)               ( (__v) & 0377)
>#define _HIGH(__v)              ( ((__v) >> 8) & 0377)
>#endif

This raises some questions.  Does the "set of symbols *defined* by
the C standard" include those *reserved* by the C standard?  2.8.1
states of the namespaces reserved by the dpANS that they are reserved
by POSIX also.

The symbols can be reserved (I hope this is inclusive) for

1) Current use by dpANS.
2) Use by alternate dpANS C implementations (including future ones).
3) Future use by POSIX.
4) Current use by POSIX as allowed by dpANS to specific implementations.

I read POSIX 1003.1 2.8.2.1 as saying that uses of the last type will
not occur.  But feature test macros macros would have to be tested
("#ifdef _FEATURE") and file scope identifiers would have to be both
defined and tested if they are used as the mechanism to allow
idempotent headers (headers capable of harmless multiple inclusion, as
required by dpANS and POSIX).

This point is academic from the point of view of the application,
since dpANS prohibits its use of the reserved namespace, anyway
(otherwise behavior is undefined - dpANS 4.1.2.1).  However it does
seem relevant to the POSIX implementer.

Assume I am created headers for a POSIX implementation.  I am
providing an ANSI C comforming compiler, and anticipate others will be
added by third parties.  These are entitled to use the namespace of
identifiers starting with underscore as they please.  But in my
headers I am required to use precisely this namespace for my feature
test macros.  What prevents them from conflicting with a dpANS
compiler (say, a future version of GNU C) that someone ports to my
POSIX implementation?

In quaranteeing header idempotence, I seem to have a choice of 1)
using reserved identifiers and risking conflicts with the dpANS
implementation and 2) using non-reserved identifiers and risking
conflicts with the application's namespace.  Am I missing something?
Might each dpANS implementation ported to a POSIX implementation
require its own set of POSIX headers due to namespace conflicts?
-- 

Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc.
jeffrey at algor2.ALGORISTS.COM or uunet!algor2!jeffrey
1762 Wainwright DR, Reston VA 22090

Volume-Number: Volume 17, Number 61