Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!usc!cs.utexas.edu!longway!std-unix From: jeffrey@algor2.algorists.com (Jeffrey Kegler) Newsgroups: comp.std.unix Subject: Re: Some questions about POSIX headers Message-ID: <433@longway.TIC.COM> Date: 18 Nov 89 20:30:02 GMT References: <4508@ast.cs.vu.nl> <6622@portia.Stanford.EDU> <6649@portia.Stanford.EDU> Sender: std-unix@longway.TIC.COM Reply-To: jeffrey@algor2.algorists.com (Jeffrey Kegler) Organization: Algorists, Inc. Lines: 61 Approved: jsq@longway.tic.com (Moderator, John S. Quarterman) From: jeffrey@algor2.algorists.com (Jeffrey Kegler) In article <6649@portia.Stanford.EDU> karish@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@algor2.ALGORISTS.COM or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090 Volume-Number: Volume 17, Number 61