daniel@terra.ucsc.edu (Daniel Edelson) (04/21/91)
There is no constraint to the effect: ``The #error directive shall not be present.'' Therefore, a strictly conforming program may contain #error. The question is: must a conforming implementation "successfully translate" any strictly conforming program? *) If yes, a program containing #error must produce an executable program. Implementations that don't are broken. *) If no, a conforming implementation may fail to translate any program whatsoever. What is the correct interpretation? Daniel Edelson
diamond@jit345.swstokyo.dec.com (Norman Diamond) (04/22/91)
In article <14793@darkstar.ucsc.edu> daniel@terra.ucsc.edu (Daniel Edelson) writes: >There is no constraint to the effect: > ``The #error directive shall not be present.'' >Therefore, a strictly conforming program may contain #error. Yes. >The question is: must a conforming implementation "successfully >translate" any strictly conforming program? Well, implementation limits might be exceeded and can prevent successful translation, and there's been a moderate amount of discussion about the meanings of the limits. >*) If yes, a program containing #error must produce an > executable program. Implementations that don't are broken. >*) If no, a conforming implementation may fail to translate any > program whatsoever. >What is the correct interpretation? An implementation could assert a limit of 0 (zero) #error directives, and reject a program that exceeds this limit. This is really playing low. On the other hand, to require successful acceptance of a program that contains an #error directive is also playing low, and is doing a disservice to the programmer (unless the programmer really wanted to use a #warning directive that does not exist, sigh). So, you get your choice, all implementations are correct, all are incorrect, etc. Let's just say all are ugly. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
volpe@camelback.crd.ge.com (Christopher R Volpe) (04/22/91)
In article <1991Apr22.075125.6828@tkou02.enet.dec.com>, diamond@jit345.swstokyo.dec.com (Norman Diamond) writes: |>In article <14793@darkstar.ucsc.edu> daniel@terra.ucsc.edu (Daniel Edelson) writes: |>>There is no constraint to the effect: |>> ``The #error directive shall not be present.'' |>>Therefore, a strictly conforming program may contain #error. |> |>Yes. Are we drawing any distinction between "containing an error directive" and "invoking an error directive during the course of preprocessing"??? |>Norman Diamond diamond@tkov50.enet.dec.com |>If this were the company's opinion, I wouldn't be allowed to post it. -Chris ================== Chris Volpe G.E. Corporate R&D volpecr@crd.ge.com
gwyn@smoke.brl.mil (Doug Gwyn) (04/23/91)
In article <14793@darkstar.ucsc.edu> daniel@terra.ucsc.edu (Daniel Edelson) writes: >Therefore, a strictly conforming program may contain #error. Yes. >The question is: must a conforming implementation "successfully >translate" any strictly conforming program? The exact requirement is that stated in section 1.7 of ANS X3.159-1989. Note that encountering of an #error directive does not halt translation; it merely generates a diagnostic message.
diamond@jit345.swstokyo.dec.com (Norman Diamond) (04/23/91)
In article <18721@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >In article <1991Apr22.075125.6828@tkou02.enet.dec.com>, >diamond@jit345.swstokyo.dec.com (Norman Diamond) writes: >>In article <14793@darkstar.ucsc.edu> daniel@terra.ucsc.edu (Daniel >Edelson) writes: >>>There is no constraint to the effect: >>> ``The #error directive shall not be present.'' >>>Therefore, a strictly conforming program may contain #error. >>Yes. >Are we drawing any distinction between "containing an error directive" and >"invoking an error directive during the course of preprocessing"??? I wasn't. As far as I can tell, if an #error directive is correctly processed and obeyed, the processor still has to proceed to translate the program successfully, unless an implementation limit is exceeded. For an #error directive that is (correctly) skipped due to #if, etc., I'd say the question didn't even require asking. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
steve@taumet.com (Stephen Clamage) (04/23/91)
daniel@terra.ucsc.edu (Daniel Edelson) writes: >There is no constraint to the effect: > ``The #error directive shall not be present.'' >Therefore, a strictly conforming program may contain #error. >The question is: must a conforming implementation "successfully >translate" any strictly conforming program? >*) If yes, a program containing #error must produce an > executable program. Implementations that don't are broken. >*) If no, a conforming implementation may fail to translate any > program whatsoever. >What is the correct interpretation? Not necesarily either of the above. An #error directive in a section of source code which is being ignored (#if'd out, for example) is, um, ignored. If the #error directive is processed, the standard requires that a diagnostic be issued. The standard cannot discuss issues such as "producing an executable program", since there may be no such notion in a given implementation. (What would it mean in an interpreter which never generates any machine code at all? Do you require that an interpreter generate a separately loadable and executable image to be considered conforming?) The Rationale states, "It is the intent of the Committee, however, that translation cease immediately upon encountering this directive..." The problem is that there is no way to put this language into the standard itself. The Rationale goes on to say that the alternative would be to put enough trash in the program to cause the translator to choke. This seems inelegant. Going to the explicit question: >The question is: must a conforming implementation "successfully >translate" any strictly conforming program? The answer is no, because of translation limits which may be present. A strictly conforming program (without #error directives) may be rejected by a conforming implementation if it hits all of the translation limits. (The implementation must handle at least one such program, but need not handle all such programs. This peculiarity arises from the impossibility of testing a requirement on "all programs".) -- Steve Clamage, TauMetric Corp, steve@taumet.com
diamond@jit345.swstokyo.dec.com (Norman Diamond) (04/24/91)
In article <687@taumet.com> steve@taumet.com (Stephen Clamage) writes: >daniel@terra.ucsc.edu (Daniel Edelson) writes: >>There is no constraint to the effect: >> ``The #error directive shall not be present.'' >>Therefore, a strictly conforming program may contain #error. > >The Rationale states, "It is the intent of the Committee, however, >that translation cease immediately upon encountering this directive..." Sigh, in giving my previous answer, I neglected to RTFR again. Nonetheless, my previous answer (and Mr. Clamage's) are correct according to the wording of TFS. >The problem is that there is no way to put this language into the >standard itself. There sure is. To modify Mr. Edelson's hypothesis appropriately: ``The #error directive shall not be present except in groups that are skipped under control of conditional inclusion (section 3.8.1)." In fact, such wording would mean exactly what is desired. The programmer would really have an illegal program. After all, the programmer's purpose in using #error was so that the programmer could tell itself that it made an illegal program. (The programmer in this case may be a collection of persons.) However, TFS did not include such a clean statement of the committee's intention. The combination of TFS and TFR suggests that their intention is for implementations to play low and dirty games with implementation limits. This is unfortunate. It actively discourages the idea of Quality of Implementation, instead of being neutral on such ideas. -- Norman Diamond diamond@tkov50.enet.dec.com If this were the company's opinion, I wouldn't be allowed to post it.
gwyn@smoke.brl.mil (Doug Gwyn) (04/25/91)
In article <1991Apr24.004437.26993@tkou02.enet.dec.com> diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) writes: >After all, the programmer's purpose in using #error was so that the >programmer could tell itself that it made an illegal program. How do you know what the programmer's intention might be? #error generates a diagnostic message, nothing more and nothing less. While the Rationale states an intention, the text of the standard itself does not reflect that presumed intention, and unless one stretches the meaning of section 1.7's "shall not produce output dependent on any ... implementation-defined behavior" beyond its elastic limit, a conforming implementation must accept programs that use #error. Producing a diagnostic message is not the same as not accepting the program. I don't recall how the Rationale ended up saying what it did. >However, TFS did not include such a clean statement of the committee's >intention. The combination of TFS and TFR suggests that their intention >is for implementations to play low and dirty games with implementation >limits. This is unfortunate. It actively discourages the idea of >Quality of Implementation, instead of being neutral on such ideas. Implementation limits have nothing to do with this issue. I also don't see what relevance this has for QI.
browns@iccgcc.decnet.ab.com (Stan Brown) (04/29/91)
In article <1991Apr23.000427.14716@tkou02.enet.dec.com>, diamond@jit345.swstokyo.dec.com (Norman Diamond) writes: > As far as I can tell, if an #error directive is correctly > processed and obeyed, the processor still has to proceed to translate > the program successfully, unless an implementation limit is exceeded. This is definitely false. I quote from the Rationale that accompanies the standard (sec 3.8.5, Error directive): The directive #error has been introduced to provide an explicit mechanism for forcing translation to fail under certain conditions. (Formally the Standard only requires, _can_ only require, that a diagnostic be issued when the #error directive is effected. It is the intent of the Committee, however, that translation cease immediately upon encountering this directive, if this is feasible in the implementation; further diagnostics on text beyond the directive are apt to be of little value.) Traditionally such failure has had to be forced by inserting text so ill-formed that the translator gagged on it. (emphasis in original) So we have the official interpretation that a program can die upon reading #error and producing the required diagnostic, but that the implementation is within its rights in continuing translation. That much is clear. What I don't understand is why the standard could not explicitly require an immediate end to translation? Stan Brown, Oak Road Systems, Cleveland, Ohio, USA +1 216 371 0043 email (until 91/4/30): browns@iccgcc.decnet.ab.com My opinions are mine: I don't speak for any other person or company.
gwyn@smoke.brl.mil (Doug Gwyn) (04/30/91)
In article <4392.281abeb4@iccgcc.decnet.ab.com> browns@iccgcc.decnet.ab.com (Stan Brown) writes: >So we have the official interpretation that a program can die upon >reading #error and producing the required diagnostic, ... No, you do NOT have an official interpretation of this issue. I personally think the Rationale is incorrect on this, and would have to vote on the other side if a request for interpretation reaches X3J11.