Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!think.com!mintaka!bloom-picayune.mit.edu!news
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: Behavior of #error preprocessor directive
Summary: sorry; Rationale says it should terminate
Message-ID: <1991Jan9.232246.19056@athena.mit.edu>
Date: 9 Jan 91 23:22:46 GMT
References: <1192@van-bc.wimsey.bc.ca> <14792@smoke.brl.mil>
Sender: news@athena.mit.edu (News system)
Reply-To: scs@adam.mit.edu
Organization: Thermal Technologies, Inc.
Lines: 99

In article <1192@van-bc.wimsey.bc.ca> jtc@van-bc.wimsey.bc.ca (J.T. Conklin) writes:
>Is use of the #error preprocessor directive required (or permitted) to
>halt compilation of a source module.
>I ask this because I believe both behaviors (halting or continuing)
>are useful.  But it would be even more useful if both mechanisms were
>available separately.

I agree wholeheartedly.  If I had to choose just one, I'd prefer
print-error-and-continue, which is what Henry and Doug have
implied #error really is, but read on.

In article <1991Jan8.011940.26586@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>Permitted but not required.  The whole area of response to errors is outside
>the scope (as eventually decided) of the standard.

The relevant section is 3.8.5, which states simply that #error
"causes the implementation to produce a diagnostic message that
includes" the user's message text.  However, the Rationale
asserts that "It is the intent of the Committee... 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."

Assuming, then, that implementors follow the Rationale as well as
the Standard, programmers can't assume that translation will
continue after an #error.

In article <14792@smoke.brl.mil> gwyn@smoke.brl.mil (Doug Gwyn) writes:
>In article <1192@van-bc.wimsey.bc.ca> jtc@van-bc.wimsey.bc.ca (J.T. Conklin) writes:
>>In any case, was anything like my #warning directive discussed during
>>the standardization process?
>
>Yes.  We spelled it #error, though.

The Rationale disagrees.  (I'm not arguing with Doug; I'd prefer
his interpretation.  The "intent of the Committee" as stated in
Rationale section 3.8.5 is nowhere else evident, and refers
either to language in an earlier Draft which has since been
deleted, or to unpublished X3J11 discussions which the
Rationale's author is relaying to us.)  As it stands, #error is
most likely to be interpreted by a compiler as fatal, and useful
print-error-message-and-continue functionality is truly missing.

This is where #pragma gets handy.  #pragma is specifically the
escape hatch for all sorts of useful creeping featureism; I would
propose

	#pragma warning pp-tokens
	                         opt

for any implementor who wishes to provide a print-error-message-
and-continue extension.  (Unfortunately, #pragma warning" is also
a likely choice for a warning level switch.)  Note that this is a
"nice" #pragma: it doesn't affect the interpretation of the rest
of the source code (i.e. it doesn't change the language accepted,
which is something that debate on comp.std.c frequently suggests
#pragma should not do).

(Actually, if I got to choose two features, I'd probably pick
print-message-and-continue and abort-compilation; it seems more
orthogonal to have user-requested compilation abortion separated
from user-requested error message printing.)

If anyone is wondering what the fuss is about, it's just an
extension of the notion that useful compilers process as much of
a source file as they can, even in the presence of errors, rather
than aborting on the very first error.  It's true that some of
the conditions under which programmers would make use of #error
would best be fatal, but I suspect (unproven assertion) that the
majority would not be so fatal that all further compilation would
be pointless.

One final point: Doug continues:
>Note that code intended to be compiled (with appropriate conditionalizing)
>by both ANSI and pre-ANSI compilers should not use #error, because many
>pre-ANSI C preprocessors would terminate fatally upon seeing #error, even
>in #ifed-out source code.  Thus I tend to still use the kludge
>	#if SOME_EXPR
>	#include "*** ERROR -- SOME_EXPR ***"
>	#endif
>which has a more drastic effect than #error anyway.

Here is another useful kludge, though less portable.  (I'm sure
Doug has seen it; others may not have.)

	#if SOME_EXPR
	 #error SOME_EXPR
	#endif

(There's a space before #error.)  "Most" pre-ANSI compilers
(where "most" is of course defined as "all the ones *I've* ever
used :-) ) can't deal with spaces before #directives, and choke
unless they're #ifdeffed out, in which case they don't care.  The
disadvantage is that they don't generally choke with the message
you've specified.  The advantage is that you do get an honest-to-
goodness #error on an ANSI compiler.

                                            Steve Summit
                                            scs@adam.mit.edu