Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!abvax!iccgcc!browns From: browns@iccgcc.decnet.ab.com (Stan Brown) Newsgroups: comp.std.c Subject: Re: #error Message-ID: <4392.281abeb4@iccgcc.decnet.ab.com> Date: 28 Apr 91 17:23:16 GMT References: <14793@darkstar.ucsc.edu> <1991Apr22.075125.6828@tkou02.enet.dec.com> <18721@crdgw1.crd.ge.com> <1991Apr23.000427.14716@tkou02.enet.dec.com> Lines: 30 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.