jeffrey@algor2.algorists.com (Jeffrey Kegler) (09/11/89)
In article <6117@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >How about the limitation in significant characters in external >symbols? That one's much more irritating. Actually, as a corollary to a discussion I initiated in comp.std.c, use of 31 significant characters in externals is as conforming to ANSI C as anything. This follows from the fact that no non-trivial strictly conforming programs exist. I won't repeat the argument which shows this, but it is based on the fact that 2.2.4.1 accepts as conforming many implementations which impose extra limits on the program, so that few, if any, programs will be acceptable to all implementations. (The clearest explanation of this is in the Rationale.) Any test suite for ANSI C, must impose additional, "reasonable" constraints on conforming implementations, constraints which the dpANS explicitly refuses to impose. Hence, failure to pass a test suite cannot prove noncompliance with dpANS, only, at most, noncompliance with a "reasonable" interpretation of it. The insistence on strict conformance in working code is, therefore, pointless. Insisting on 31 significant initial characters in a "reasonably" compliant implementation is as "reasonable" an interpretation of the standard as can be made. The number 31 makes externals orthogonal with internal identifiers and macro names. The dpANS explicitly (Footnote 8 and the Rationale 2.2.4.1) calls upon vendors to be expansive in their interpretation of system limits. Stricter limits on externals are explicitly deprecated in 3.9.1. Given the politics of X3J11, it might have been unreasonable to expect more of the dpANS. I can imagine some large vendors saying to their rep to X3J11, "Have fun, but remember, if you do anything that requires a change to our installed base of mainframe OSes, you can kiss a promising career goodbye." A usable definition of strict conformance may not have been possible. I think the most important thing dpANS had to do was avoid imposing a burden on future compilers and standards. In this (difficult) task, they succeeded. What may be appropriate is another C standard effort, whose charter does not allow them to contradict the ANSI Standard, but which allows them to extend it, and to further restrict conforming implementations than X3.159 was able to do. Given the basis laid by dpANS, this effort will be made far easier. -- Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc. jeffrey@algor2.ALGORISTS.COM or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/12/89)
In article <1989Sep10.234151.14314@algor2.algorists.com> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >This follows from the fact that no non-trivial strictly conforming >programs exist. That's utterly false. I write such programs all the time. >I won't repeat the argument which shows this, but it is based on the >fact that 2.2.4.1 accepts as conforming many implementations which >impose extra limits on the program, so that few, if any, programs >will be acceptable to all implementations. But that's not the criterion for a strictly conforming program! In practice, ANY implementation has to have SOME additional restrictions beyond the constraints of the Standard. X3J11 recognized this. >Any test suite for ANSI C, must impose additional, "reasonable" >constraints on conforming implementations, constraints which the dpANS >explicitly refuses to impose. Hence, failure to pass a test suite >cannot prove noncompliance with dpANS, only, at most, noncompliance >with a "reasonable" interpretation of it. This too is false. If the test suite indicates the reason for failure to pass, it should be a simple matter to determine if it's due to the implementation failing to meet the Constraints and Semantics requirements, or to a deficiency in the test suite itself (such as being too large for the implementation). >The insistence on strict conformance in working code is, therefore, >pointless. Not at all. It's an important part of a viable portability strategy. >Insisting on 31 significant initial characters in a "reasonably" >compliant implementation is as "reasonable" an interpretation of the >standard as can be made. That too is false. The Standard is quite explicit about this. Only six characters, monocase, of significance in external identifiers is required of conforming implementations. >I can imagine some large vendors saying to their rep to X3J11, "Have >fun, but remember, if you do anything that requires a change to our >installed base of mainframe OSes, you can kiss a promising career >goodbye." This verges on libel. I've had many off-the-record discussions with X3J11 members, and never saw any sign of such pressure. Nearly all votes on technical issues were by show of hands, with no specific names recorded, thus no way for employers to know how representatives were voting the issues. Certainly there was a deliberate effort to accommodate the widest feasible range of computing environments, but in all cases a majority of the committee had to be convinced, so any narrow special-interest concern would have to be convincingly presented as beneficial to C programming as a whole before it would be adopted. I believe that X3J11 members "voted their conscience" most of the time. >What may be appropriate is another C standard effort, whose charter >does not allow them to contradict the ANSI Standard, but which allows >them to extend it, and to further restrict conforming implementations >than X3.159 was able to do. I think you have "gone off the deep end" upon discovering that we were unable (for PRACTICAL, not POLITICAL, reasons) to force ALL conforming implementations to accept ALL strictly conforming programs. All that trying to impose such a constraint would accomplish would be to reduce the availability of Standard C; in lieu of standard conformance, who knows what a C implementation would look like on the other systems. It would be an immense disservice to make the standard unduly restrict the environments in which Standard C is available.
jeffrey@algor2.algorists.com (Jeffrey Kegler) (09/12/89)
In article <11027@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >In article <1989Sep10.234151.14314@algor2.algorists.com> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >>This follows from the fact that no non-trivial strictly conforming >>programs exist. > >That's utterly false. I write such programs all the time. > >>I won't repeat the argument which shows this, but it is based on the >>fact that 2.2.4.1 accepts as conforming many implementations which >>impose extra limits on the program, so that few, if any, programs >>will be acceptable to all implementations. > >But that's not the criterion for a strictly conforming program! 1.7 "A strictly conforming program ... shall not produce output dependent on any ... implementation defined behavior, and shall not exceed any minimum implementation limit." Hence the mimimum implementation limits are the criterion for a strictly conforming program. The more latitude for the implementor, the less for strictly conforming programs. [ Aside: a curious exception here is reserved for programs which produce no output. ] Further on in 1.7. "A conforming hosted implementation shall accept any strictly conforming program." Similar language follows for free-standing programs. >In practice, ANY implementation has to have SOME additional restrictions >beyond the constraints of the Standard. X3J11 recognized this. And a lot more. From the Rationale 2.2.4.1: "a deficient [ but conforming ] implementation could ... succeed in being useless." The Rationale also (1.7) says that the intent was that strictly conforming programs not be required to be fully, only maximally, portable, among conforming implementations, but X3J11 did not write the definition of strictly conforming in 1.7 of the standard itself anywhere near loosely enough for that to be true. >This too is false. If the test suite indicates the reason for failure >to pass, it should be a simple matter to determine if it's due to the >implementation failing to meet the Constraints and Semantics requirements, >or to a deficiency in the test suite itself (such as being too large for >the implementation). So we would have the tester report: "The implementation failed to compile the test suite due to its size constraints, therefore the implementation passes!" > I think you have "gone off the deep end" upon discovering that we > were unable (for PRACTICAL, not POLITICAL, reasons) to force ALL > conforming implementations to accept ALL strictly conforming > programs. dpANS does force ALL conforming implementations to accept ALL strictly conforming programs, at least as far as implementation limits go (which is where the severest restrictions are). In so doing, it defines strict conformance out of existence. This may have been a good trade off (or the language in 1.7 may have been unintended), but in any case, the trade off was made. Let me apologize to those who dislike this sort of lawyerly quibble over words (and to any who might think I do it as a personal attack on anyone). As we go from working exclusively with implementations, to using standards, this sort of argumentation is inevitable. C portability previously was all in the eyes of some greybeard who remembered the Frobnitz compiler for the Kludge computer would not handle that construct. The work of X3J11 takes us out of that realm and a few quibbles over language are a small price to pay for that. -- Jeffrey Kegler, Independent UNIX Consultant, Algorists, Inc. jeffrey@algor2.ALGORISTS.COM or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/13/89)
In article <1989Sep12.160023.18723@algor2.algorists.com> jeffrey@algor2.UUCP (Jeffrey Kegler) writes: >>>I won't repeat the argument which shows this, but it is based on the >>>fact that 2.2.4.1 accepts as conforming many implementations which >>>impose extra limits on the program, so that few, if any, programs >>>will be acceptable to all implementations. >>But that's not the criterion for a strictly conforming program! >1.7 "A strictly conforming program ... shall not produce output >dependent on any ... implementation defined behavior, and shall not >exceed any minimum implementation limit." That means "any minimum implementation limit as specified by this standard", not "the most miserable possible conforming implementation". >>In practice, ANY implementation has to have SOME additional restrictions >>beyond the constraints of the Standard. X3J11 recognized this. >And a lot more. From the Rationale 2.2.4.1: "a deficient [ but >conforming ] implementation could ... succeed in being useless." The >Rationale also (1.7) says that the intent was that strictly conforming >programs not be required to be fully, only maximally, portable, among >conforming implementations, but X3J11 did not write the definition of >strictly conforming in 1.7 of the standard itself anywhere near >loosely enough for that to be true. Programming for portability is an art; it cannot be forced by any amount of legislation. Certainly, a strictly conforming program could be devised that would place such heavy demands on compiler symbol tables, for example, that it could not be successfully compiled on the largest existing computer. That is why "strict conformance to the standard" is not 100% synonymous with "totally portable to all conforming implementations". The idea, as I said earlier and is also addressed by the Rationale, is for "strict conformance" to serve as an important guideline for writing maximally portable C programs. That does not mean that there are not other considerations that also need to be addressed. >So we would have the tester report: "The implementation failed to >compile the test suite due to its size constraints, therefore the >implementation passes!" Get real. That's not what C conformance test suites actually do. A realistic message might be "TEST # 1234: implementation fails to perform the usual arithmetic conversions properly in this case: ..." The idea is to test the grammar, constraints, and semantics supported by the implementation. A properly-designed conformance test suite steers clear of pushing all the required minimum limits at the same time; it is the implementor's responsibility to provide the one example program that meets all these limits simultaneously as called for by the standard. That sample program is to be inspected as one conformance criterion. >dpANS does force ALL conforming implementations to accept ALL strictly >conforming programs, at least as far as implementation limits go ... Walter Murray pursued this thread in comp.std.c. I now admit to not knowing what distinction was intended between "accepting" a program and "translating" and guaranteeing executability for a program. The two sets of relevant wording in the proposed standard seem to be at odds on this. >The work of X3J11 takes us out of that realm >and a few quibbles over language are a small price to pay for that. These are important issues, perhaps worth formally requesting clarification from X3J11. Disclaimer: I'm merely expressing my own notions and confusion, not necessarily X3J11's.