bdm659@csc.anu.oz (10/29/89)
From a recent too-hasty posting of mine: >> Section 3.3.9 (on pointer equality): >> "If two pointers to object or incomplete types compare equal, >> they point to the same object." > > Marv Rubinstein informs me that in the draft of Dec. 7 1988 it says > "If two pointers to object or incomplete > types are both null, they compare equal." > Query: > Has the sentence from 3.3.9 in the ">>" section above been modified to avoid > the contradiction? (I quoted it from a posting of Bill Wells. My copy of > the draft is so old that it doesn't have it at all.) I should have stayed in bed this morning. The e-mail I received from Marv quite clearly stated that the sentence I quoted above from 3.3.9 has been expanded to include the possibility of null pointers, as well as pointers just past the end of the same array. In that case, it seems that many little problems earlier drafts had concerning pointer comparison have been fixed. In summary, the BEST answer to the question "does (int*)0 != (int*)0 really follow from the two sentences I quoted?" is "who cares? the standard doesn't say that any more." I'm sorry if I misled anyone. [Vanishes in a puff of smoke made from the burning of old drafts.] > Brendan McKay. ============================================================= > bdm@anucsd.oz or bdm@anucsd.oz.au (via uunet.uu.net)
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/30/89)
In article <879.254a0ba0@csc.anu.oz> bdm659@csc.anu.oz writes: >problems earlier drafts had concerning pointer comparison have been fixed. >In summary, the BEST answer to the question >"does (int*)0 != (int*)0 really follow from the two sentences I quoted?" is >"who cares? the standard doesn't say that any more." There is another point worth making here. The Standard must be subjected to more than mere "linguistic analysis" in order to understand what it is saying; there is a gestalt that must be acquired, and it goes beyond the simple expansion of words in terms of their definitions, just as concepts in general embody much more than is found in their literal definitions. For instance, although "(int*)0" does indeed have type "pointer to int", it does not point to an int. Moreover, no pointer of type "void*" points to any datum having type "void"; there are no void objects in C as specified by the Standard (despite arguments from some of us that there should be). Yet simple elaboration of "pointer to X" might mislead one to think that such a thing points to X. These technical terms are used in subtly tricky ways, and must be understood in the total context of the language specification.
tneff@bfmny0.UU.NET (Tom Neff) (10/31/89)
In article <11441@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >There is another point worth making here. The Standard must be >subjected to more than mere "linguistic analysis" in order to >understand what it is saying; there is a gestalt that must be >acquired, and it goes beyond the simple expansion of words in >terms of their definitions, just as concepts in general embody >much more than is found in their literal definitions. This suggests a good preface quote for the Standard in its final published form: "Never mind what I say, just do what I tell you." -- "Of course, this is a, this is a Hunt, you | Tom Neff will -- that will uncover a lot of things. | tneff@bfmny0.UU.NET You open that scab, there's a hell of a lot of things... This involves these Cubans, Hunt, and a lot of hanky-panky that we have nothing to do with ourselves." -- RN 6/23/72
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/31/89)
In article <14820@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >In article <11441@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>There is another point worth making here. The Standard must be >>subjected to more than mere "linguistic analysis" in order to >>understand what it is saying; there is a gestalt that must be >>acquired, and it goes beyond the simple expansion of words in >>terms of their definitions, just as concepts in general embody >>much more than is found in their literal definitions. >This suggests a good preface quote for the Standard in its final >published form: > "Never mind what I say, just do what I tell you." Who is being quoted? My point is that Linguistic Analysis is bogus in philosophy and it is equally bogus in understanding the C Standard, because one gets too concerned with classifying trees and misses seeing the path through the forest. Obviously, there has been a lot of effort put into getting the wording in the specifications right, but focusing attention too narrowly on the wording while disregarding the concepts leads to silly interpretations of what X3.159 is trying to say. That would be inevitable no matter what wording had been used, unless the entire document were a huge tract of formalism (such as denotational semantics); X3J11 rejected that path as being of little value to the typical programmer or implementor.
bdm659@csc.anu.oz (10/31/89)
In article <11441@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: > > There is another point worth making here. The Standard must be > subjected to more than mere "linguistic analysis" in order to > understand what it is saying; there is a gestalt that must be > acquired, and it goes beyond the simple expansion of words in > terms of their definitions, just as concepts in general embody > much more than is found in their literal definitions. That's clearly true, though one valid measure of the success of the standard is how readily an "average technically competent person" can acquire that gestalt by studying the document. It's also true that it would be unfair to expect a technical document of this complexity to have the rigor and internal consistency that we might expect of a mathematical proof. That doesn't mean that inconsistencies shouldn't be pointed out (I intend to--this isn't sacred scripture); it means that they need not be taken too seriously unless they are genuinely likely to mislead someone. I'm told that the sentence I quoted from 3.3.9 now reads "If two pointers to object or incomplete types compare equal, they both are null pointers, or both point to the same object, or both point one past the last element of the same array object.". The previous version of the sentence was simply false. [It used to be much worse, though. I'm fairly sure that the draft of May 87 is literally satisfied by an implementation in which all pointers compare equal always.] Brendan McKay. bdm@anucsd.oz or bdm@anucsd.oz.au