bph@buengc.BU.EDU (Blair P. Houghton) (05/26/90)
In article <12987@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In article <265C5E18.4200@paris.ics.uci.edu> rfg@ics.uci.edu (Ronald Guilmette) writes: >>I believe that he [Blair] has indeed located a contradiction that requires >>correction (and not just clarification). > >Now, hey, I'm the one who pointed that out. Well, hey, you didn't actually point it out, you simply said it was there, and even then you had it wrapped in a much larger indication of ambiguity; and, Ron is saying he agrees with me that an interpretation won't be sufficient. I don't know the exact definition of "interpretation" as CBEMA and X3J11 would define it, but if it's what I think it is (i.e., "putting into other words an existing statement"), it can't be done given the current statements in the standard. The "interpretation" will instead have to be a "redefinition". I'll agree with your "correction is out of the question" insofar as it's way too soon after the finalization of the standard to rewrite the thing. Some time should be taken so that more of these things can be found, or it will become ridiculously expensive to the entire industry to even have a standard. Otherwise, we might as well have spent the time and money on cross-compilers and MyC-to-YourC translators. Is there any way to elect and publish amendments to an ANSI document without having to reapparove and reprint the entire thing? >Indeed, it's my main >reason for thinking the alternative interpretation that I've been >proposing needs to be seriously considered as the one intended. I think that if you keep the implications of the examples (pp. 73ff.) you can get the sense you want. The basic rules seem to be: "If the left brace aligns with the first named member of an aggregate, then the brace-enclosed initializer-list initializes the entirity of that aggregate; otherwise it initializes the scalar[*]. If the first member of an aggregate aligns with no left brace in the initializer-list, then the aggregate is initialized by taking the initializers in the order in which they appear in the initializer-list; initializers 'left over' when the aggregate is fully initialized will be used for the next object, if the aggregate was part of a larger aggregate. An aggregate is an aggregate is an aggregate, no matter whether it contains or is contained by other aggregates." The alternative, as Ronald says, and I prefer this one, would be that "initializers for aggregate objects, whether they are members of other aggregate objects or not, shall have braces". But, this contravenes just about every example, and may break existing code, which is why I'd support the other definition. [*] The rules already exist for what happens if you try to initialize a scalar with an initializer-list that has too many things in it; and it seems to say that the commas could be taken as comma-operators in an assignment-expression... here you need an interpretation... would the comma-operator take precedence over the comma-separator, or vice versa? --Blair "Uh-ohhhhhh..."
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/26/90)
In article <5910@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >Is there any way to elect and publish amendments to an ANSI >document without having to reapparove and reprint the entire thing? Printing doth not an ANS make. There is an entire process that must be gone through, and we just finished one such. (It took several years.) There is no way to change the official ANS for C through short-cuts. However, it is possible for X3J11 to prepare for release "information bulletins" containing interpretation of the standard; of course the interpretation should be exactly that and not some wild contradiction of what the standard actually says. Such interpretations would not have the legal force of "standard", but we do expect that as civilized cooperative gentlemen everyone involved would agree to be guided in THEIR interpretation of the standard by these official bulletins.
diamond@tkou02.enet.dec.com (diamond@tkovoa) (05/29/90)
In article <13002@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >... interpretation of the standard; of course the >interpretation should be exactly that and not some wild contradiction >of what the standard actually says. Huh? Some of the interpretations already wildly contradict what the standard actually says. To be more precise, the standard says some things that are wildly different from what was intended, and the interpretations made a lot more sense. >Such interpretations would not have the legal force of "standard", We would certainly be better off giving precedence to the interpretations (at least those already issued) over the wording of the standard itself. >but we do expect that as civilized cooperative gentlemen Indeed, in this field, most of the civilized cooperative gentlepersons are civilized cooperative gentlemen. (And the ratio is similarly lopsided for those who are uncivilized and/or uncooperative.) But let's express hopes for ALL civilized cooperative gentlepersons. >everyone involved would agree to be guided in >THEIR interpretation of the standard by these official bulletins. -- Norman Diamond, Nihon DEC diamond@tkou02.enet.dec.com Proposed group comp.networks.load-reduction: send your "yes" vote to /dev/null.
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/29/90)
In article <1741@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >In article <13002@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >>... interpretation of the standard; of course the >>interpretation should be exactly that and not some wild contradiction >>of what the standard actually says. >Huh? Some of the interpretations already wildly contradict what the >standard actually says. To be more precise, the standard says some >things that are wildly different from what was intended, and the >interpretations made a lot more sense. Name one. There has been NO information bulletin so far, and only six official individual replies to interpretation requests, which I here summarize (disclaimer: this posting is NOT an official document): #1. Still being discussed by committee; no resolution yet. #2. Was a request for changes, not for interpretation. #3. Was a request for changes, not for interpretation. #4. Was disambiguated by an editorial change in the final standard. #5. A strictly conforming program may not contain #pragma, because as the standard explicitly states, a pragma causes the implementation to behave in an implementation-defined manner. #6. strtoul() conversion of a string starting with a minus sign reports a range error if and only if the rest of the subject sequence would overflow the range of unsigned longs, otherwise the value is negated as an unsigned long. This is the only sensible way to interpret what the standard states for this process. So which of these "wildly contradict what the standard actually says"?
diamond@tkou02.enet.dec.com (diamond@tkovoa) (05/30/90)
In article <13011@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >In article <1741@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >>In article <13002@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >>>... interpretation of the standard; of course the >>>interpretation should be exactly that and not some wild contradiction >>>of what the standard actually says. >>Huh? Some of the interpretations already wildly contradict what the >>standard actually says. To be more precise, the standard says some >>things that are wildly different from what was intended, and the >>interpretations made a lot more sense. > >Name one. There has been NO information bulletin so far, and only six >official individual replies to interpretation requests, which I here >summarize (disclaimer: this posting is NOT an official document): >... I thought there were more than six topics in one of your previous postings, which was a very informative and helpful (though unofficial) summary of interpretations. (And I thank you for having posted that.) Two of the interpretations, which were themselves very informative and helpful, which wildly contradicted the standard, involved the persistency of blue paint, and the prohibition of multiple definitions of an external function when the function never occurs in an expression. These two do not appear to be among the six in your present posting (which I replaced by the ellipsis above). Have they been "uninterpreted"? -- Norman Diamond, Nihon DEC diamond@tkou02.enet.dec.com Proposed group comp.networks.load-reduction: send your "yes" vote to /dev/null.
gwyn@smoke.BRL.MIL (Doug Gwyn) (05/30/90)
In article <1753@tkou02.enet.dec.com> diamond@tkou02.enet.dec.com (diamond@tkovoa) writes: >Two of the interpretations, which were themselves very informative >and helpful, which wildly contradicted the standard, involved the >persistency of blue paint, and the prohibition of multiple definitions >of an external function when the function never occurs in an expression. The other items in my meeting summary posting were not official interpretation rulings, but a combination of answers to informal letters and results of discussions about issues raised by members of X3J11. (For example, I collected a bunch of e-mail discussing issues about which I wasn't entirely sure of the correct answers, and took it to the meeting for discussion by one of the subgroups formed to draw up responses to both formal and informal questions.) "Blue paint persists" really IS a literal reading of the standard (3.8.3.4). It was reaffirmed that yes, we really meant that, and that if it had been intended that the blue paint evaporate at some point there would have been an additional statement in the standard to that effect. 3.7 Semantics says: If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof operator), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no more than one. The last clause was added editorially in the process of preparing the final document for ANSI, and was ratified unanimously by X3J11 as such. It was deemed a simple oversight, fixed in the final standard.