🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #3407

#error (was: Re: #warning)

#3407
From: Fergus Henderson
Date: Thu, 22 Feb 1996 18:14
100 lines
4027 bytes
clamage@Eng.sun.com (Steve Clamage) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>>clamage@Eng.Sun.COM (Steve Clamage) writes:
>>>
>>>The description of #error says only that it
>>>"causes the implementation to produce a diagnostic message that includes
>>>the specified sequence of preprocessing tokens."
>>
>>Isn't this a bug in the standard?  Doesn't this mean that
>>
>>	#error foobar
>>	int main() { return 0; }
>>
>>is a strictly conforming program?  Yet no compiler I know of will accept it!
>
>It is a strictly conforming program (although we don't use that terminology
>in the C++ standard).

OK, so we are agreed so far.

>The implementation must tell you what the effect of #error is.

What makes you think that?  As far as I can tell, it is not in the
least bit justified by the draft standard.  Here's the complete
description of #error:

|   16.5  Error directive                                      [cpp.error]
| 
| 1 A preprocessing directive of the form
|           # error pp-tokensopt new-line
|   causes  the  implementation  to  produce  a  diagnostic  message  that
|   includes the specified sequence of preprocessing tokens.

It doesn't say anything about implementation-defined behaviour or the
implementation being required to document anything.

>If the effect is to abort compilation, that is allowed.

Again, what makes you think that?

Is the implementation allowed to abort compilation if it sees a #define?

>>Surely the semantics specified for #error should say that it has the effect
>>of making the translation unit ill-formed.
>
>Why?

So that you can be sure that a translation unit with #error in it will
not be accepted by any sane implementation.

>You can write ill-formed code if you want to. For example:
>	#if undesirable_condition
>	this phrase should not be seen by the compiler
>	#endif

But I shouldn't have to.  I'd much rather write just

	#if undesirable_condition
	#error "undesirable_condition occurred"
	#endif

than

	#if undesirable_condition
	this phrase should not be seen by the compiler
	#endif

or

	#if undesirable_condition
	#error "undesirable_condition occurred"
	this phrase should not be seen by the compiler
	#endif

and I would still like to be sure that conforming compilers do not accept
the code if undesirable_condition is true.

According to the current wording, conforming compilers are *required*
to accept #error!

Obviously this is a mistake; it needs to be fixed.

>The #error directive is part of the language, and I think it would be a
>contradiction in terms to say that a valid language construct is ill-formed.

The #error itself is not ill-formed; the translation unit containing it is,
unless the #error is skipped via conditional compilation.  There is no
contradiction there.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]
Technical Details
Message-ID: <4gibn8$6pg@mulga.cs.mu.OZ.AU>
Path: arc1-ca.pugleaf.net!chronicle.mti.sgi.com!austern
References: <4g91rh$kgn@mulga.cs.mu.OZ.AU> <4gdcvn$cqv@engnews1.Eng.Sun.COM>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!chronicle.mti.sgi.com!austern
From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.std.c++
Subject: #error (was: Re: #warning)
Date: 22 Feb 1996 10:14:55 PST
Organization: Comp Sci, University of Melbourne
Approved: austern@isolde.mti.sgi.com
Message-ID: <4gibn8$6pg@mulga.cs.mu.OZ.AU>
References: <4g91rh$kgn@mulga.cs.mu.OZ.AU> <4gdcvn$cqv@engnews1.Eng.Sun.COM>
NNTP-Posting-Host: isolde.mti.sgi.com
X-Original-Date: 22 Feb 1996 18:12:56 GMT
X-Auth: PGPMoose V1.1 PGP comp.std.c++
 iQBVAwUBMSyyzEy4NqrwXLNJAQGkKwH+NZP6XPPsaOKNpIb7B/RPYkaPwcRCVd5z
 Kkb+au26uAAuEle9OwG8O9ZK9LdkRx8iqkAk9KdltE9bmqLs/KLM4Q==
 =RW/c
Originator: austern@isolde.mti.sgi.com