Article View: comp.std.c++
Article #3407#error (was: Re: #warning)
From: Fergus Henderson
Date: Thu, 22 Feb 1996 18:14
Date: Thu, 22 Feb 1996 18:14
100 lines
4027 bytes
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!austernReferences:
<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