114 SEPTEMBER 1999 Embedded Systems Programming
NIGEL JONES
feature
ne of the least used but
potentially most useful
preprocessor directives is
#error. I would guess
that only a small percent-
age of the readers of this
article know what
#error is, and an
even smaller percentage have actually
used it. This is a shame, because
#error has a couple of uses that are
invaluable for making your life a lot
easier.
So what exactly is the
#error direc-
tive and what does it do? It’s an ANSI-
C specified preprocessor directive. Its
syntax is very straightforward, as you
can see:
#error <writer supplied error mes-
sage>
The <writer supplied error mes-
sage> is optional (although it never
really makes sense to omit it) and can
consist of any printable text. You don’t
even have to enclose the text in
quotes.
When the preprocessor encounters
a
#error statement, it causes compila-
tion to terminate and the writer-sup-
plied error message to be printed to
stderr. A typical error message from a
compiler looks like this:
Filename(line_number): Error!
Ennnn: writer supplied error message
where Filename is the source file name,
line_number is the line number where
the
#error statement is located, and
Ennnn is a compiler-specific error num-
ber. Thus, the error message is basical-
ly indistinguishable from ordinary
compiler error messages.
“Wait a minute,” you might say. “I
spend enough time trying to get code
to compile and now he wants me to do
something that causes more compiler
errors?” Absolutely! The essential
point is that code that compiles but is
incorrect is worse than useless. I’ve
found three general areas in which this
In Praise of the
#error Directive
The #error directive may not be a widely used preprocessor directive, but according to the
author, it can make your life easier. Here’s his case.
O
RETURN
