gwyn@brl.arpa (Doug Gwyn) (11/16/89)
From: gwyn@brl.arpa (Doug Gwyn) 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: No, it doesn't -- because "the set of symbols defined by the C standard" can, and must, be construed as permitting all symbols that the C standard specifically reserves for the implementation, including _LOW etc. >A header that conforms to POSIX 1003.1 as well as to the SVID and >X/OPEN standards will be a bit complicated. A SVID-conforming program >that doesn't use POSIX extensions will expect UNIX identifiers to be >visible in the headers without use of a feature test macro. That's true, but it's easily accomplished: the implementation merely needs to provide separate ways of invoking the compiler for POSIX/ANSI_C and "traditional" UNIX environments, in the latter case predefining some feature-test macro used to enable "traditional" extensions in the standard headers. Of course the feature-test macro used for this must be in the name space reserved for implementations. >Section 2.2.4 says "Any invocation of a library function that is >implemented as a macro shall expand to code that evaluates each of its >arguments only once ...". However, WIFSIGNALED is defined in the >Standard as a macro, not as a library function. It's legal to >evaluate these arguments twice; maybe not wise but, strictly >speaking, legal. Again, that depends on how one interprets the wording. Just because the spec requires that a particular "library function" be implemented as a macro does not keep it from being a library function implemented as a macro! (And therefore subject to IEEE 1003.1 2.2.4.) You can't argue that "library function" means genuine C function as opposed to function-like macro, either, because if that were a valid interpretation what would be the point of 2.2.4 talking about "library function that is implemented as a macro"? I think the sanest interpretation is that even the things specifically stated in the spec to be (function-like) macros must be implemented to evaluate each of their arguments only once per macro invocation. Thus, the WIFSIGNALED implementation you cited would be non-POSIX in that respect. Perhaps the 1003.1 working group should clarify this along with the other post-publication changes they have planned. Volume-Number: Volume 17, Number 57
karish@forel.stanford.edu (Chuck Karish) (11/18/89)
In article <428@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote: >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: > >No, it doesn't -- because "the set of symbols defined by the C standard" >can, and must, be construed as permitting all symbols that the C standard >specifically reserves for the implementation, including _LOW etc. To me, "the set of symbols defined by the C standard" means the set of symbols defined, not the set of all possible symbols in some part of the name space. I interpreted this to mean the set of symbols listed in Appendix 3 of X3J11/88-158 (Draft ANSI C Standard). "Defined" and "reserved" denote different concepts. This is cleared up somewhat in Drafts 3 and 4 of the P1003.1a supplement: 2.8.2: "It is unspecified by this standard whether any symbols in the namespace reserved to the implementation are affected by _POSIX_SOURCE." 2.8.2.2: "If _POSIX_SOURCE is defined ... [s]ymbols from the namespace reserved for the implementation, as defined by the C Standard [1], are also permitted." Note that neither of these clauses deals with the case where _POSIX_SOURCE is not defined, which is the case I considered in the paragraph quoted from my earlier article [2.8.2.1]. If the 1003.1 committee means that anything in the implementors' name space may be in a header without protection, the standard must say so. As now written, it explicitly says the opposite. Chuck Karish karish@mindcraft.com (415) 323-9000 karish@forel.stanford.edu Volume-Number: Volume 17, Number 59
jeffrey@algor2.algorists.com (Jeffrey Kegler) (11/19/89)
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
gwyn@BRL.MIL (11/19/89)
In article <431@longway.TIC.COM> karish@forel.stanford.edu (Chuck Karish) writes:
-In article <428@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote:
->No, it doesn't -- because "the set of symbols defined by the C standard"
->can, and must, be construed as permitting all symbols that the C standard
->specifically reserves for the implementation, including _LOW etc.
-To me, "the set of symbols defined by the C standard" means the set of
-symbols defined, not the set of all possible symbols in some part of
-the name space. I interpreted this to mean the set of symbols listed
-in Appendix 3 of X3J11/88-158 (Draft ANSI C Standard). "Defined"
-and "reserved" denote different concepts.
But IEEE Std 1003.1 cannot constrain the identifiers reserved for
implementation use by ANSI X3.159. The intention of this part of
the 1003.1 spec is quite clear -- it means that applications cannot
count on the symbols defined by 1003.1 as being visible in the
Standard C headers unless _POSIX_SOURCE is defined before including
the headers. It does not impose additional constraints on the pure
X3.159 part of the implementation. As a practical matter, it cannot
forbid use of the implementation-reserved identifiers, because they
are necessary in many environments in order to correctly implement
X3.159.
-This is cleared up somewhat in Drafts 3 and 4 of the P1003.1a
-supplement:
- 2.8.2: "It is unspecified by this standard whether any symbols in
- the namespace reserved to the implementation are affected by
- _POSIX_SOURCE."
- 2.8.2.2: "If _POSIX_SOURCE is defined ... [s]ymbols from the
- namespace reserved for the implementation, as defined by the C
- Standard [1], are also permitted."
-Note that neither of these clauses deals with the case where
-_POSIX_SOURCE is not defined, which is the case I considered in the
-paragraph quoted from my earlier article [2.8.2.1].
2.8.2 obviously DOES deal with the case where _POSIX_SOURCE is
undefined, because it is the contrast between that and the case
where _POSIX_SOURCE is defined that constitutes waht is "affected
by _POSIX_SOURCE".
Note that what is defined by the standard headers when _POSIX_SOURCE
is not defined is ENTIRELY specified by X3.159, not by 1003.1.
-If the 1003.1 committee means that anything in the implementors'
-name space may be in a header without protection, the standard
-must say so. As now written, it explicitly says the opposite.
You are being deliberately obtuse. I don't think anybody involved
with drawing up these specifications would back your interpretation.
[ Let's avoid personal characterisations and stick to technical points,
please. -mod ]
- D A Gwyn
acting X3J11/1003.1 liaison
Volume-Number: Volume 17, Number 60karish@forel.stanford.edu (Chuck Karish) (11/21/89)
From: karish@forel.stanford.edu (Chuck Karish) In article <432@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote: >In article <431@longway.TIC.COM> karish@forel.stanford.edu (Chuck Karish) writes: >-In article <428@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) wrote: >->No, it doesn't -- because "the set of symbols defined by the C standard" >->can, and must, be construed as permitting all symbols that the C standard >->specifically reserves for the implementation, including _LOW etc. >-To me, "the set of symbols defined by the C standard" means the set of >-symbols defined, not the set of all possible symbols in some part of >-the name space. I interpreted this to mean the set of symbols listed >-in Appendix 3 of X3J11/88-158 (Draft ANSI C Standard). "Defined" >-and "reserved" denote different concepts. > >But IEEE Std 1003.1 cannot constrain the identifiers reserved for >implementation use by ANSI X3.159. Agreed. >The intention of this part of >the 1003.1 spec is quite clear -- it means that applications cannot >count on the symbols defined by 1003.1 as being visible in the >Standard C headers unless _POSIX_SOURCE is defined before including >the headers. It does not impose additional constraints on the pure >X3.159 part of the implementation. If the intention were "quite clear" as expressed in the document, this thread wouldn't exist. The relevant sentence from 1003.1 is: "If there are no feature test macros present in a program, only the set of symbols defined by the C standard shall be present". From this wording, the reader has no immediate way to tell that the set of allowed symbols is what's meant, rather than the specific symbols required by the C standard; that "defined" modifies "set", not "symbols". This ambiguity has led some readers of 1003.1 to look in the C standard for a list of defined symbols, and to find Appendix 3. Under this interpretation, 1003.1 excludes implementation-defined symbols from the standard headers. >You are being deliberately obtuse. It's my job to be obtuse in cases like this, and it's yours, too. It's neither unusual nor unexpected that people involved with writing a complicated document miss some of the ambiguities it contains. It is sometimes necessary to affect a naive attitude in order to foresee how one's words might be misinterpreted. In this case, no such cupidity was necessary. The wording really is confusing. Note that I said in my first posting on this question that I was basing my answer on a literal reading of the relevant documents. If the reader needs to have special knowledge or to note every subtle nuance of meaning in order to understand a standard, the standard is inadequate. Volume-Number: Volume 17, Number 62
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (11/22/89)
From: Andy Tanenbaum <uunet!cs.vu.nl!ast> In article <434@longway.TIC.COM> karish@forel.stanford.edu (Chuck Karish) writes: >If the >reader needs to have special knowledge or to note every subtle nuance >of meaning in order to understand a standard, the standard is >inadequate. I second this 1000%. There was a comment earlier in this group to the effect "Everybody in the committee knows what it means." That is exactly the point. A standard should be written so that an outsider who was not on the committee but who is skilled in the field can pick it up and understand it. Now by-and-large, P1003.1 isn't so bad, but I am holding my breath about the ISO version. Last year I went through the ISO OSI standards very carefully. In many cases after 3 or 4 detailed readings I didn't have the slightest idea of what they were talking about (e.g. the OSI session standard has an endless amount of mumbo jumbo about how to start and end an activity, but nary a word on what an activity might be). I eventually figured out how to determine what the standard is all about-- you call up the convenor on the phone and ask him. As an outsider who is trying to implement P1003.1 (and who has not even looked at the UNIX source code), I am an interesting case in point. No doubt I'll have some questions in the course of time. Andy Tanenbaum (ast@cs.vu.nl) Volume-Number: Volume 17, Number 63