Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!hsdndev!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: #error
Message-ID: <15966@smoke.brl.mil>
Date: 24 Apr 91 19:36:59 GMT
References: <14793@darkstar.ucsc.edu> <687@taumet.com> <1991Apr24.004437.26993@tkou02.enet.dec.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 24

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.