-------
#define XYZZY 1
main() {
#if XYZZU
printf("xyzzy\n");
#else
printf("plugh\n");
#endif
}
------
Now, obviously that XYZZU was supposed to be an XYZZY, and I wanted to
conditionally compile the first piece of code, not the second. But when
I compile this, it doesn't even give me a friendly warning, and just
assumes XYZZU is 0. (Which, I understand, is in accordance with ANSI-
defined behavior.)
Now, my question is how other people avoid these same kinds of idiotic
mistakes? Even if I put in "#if !defined(XYZZY)..." type things for
every define, it still wouldn't catch all typos. There should be some
way to avoid this idiotic kind of error...
--
Jim Seidman (Drax), the accidental engineer.
"There's a certain freedom to being completely screwed." - The Freshman
UUCP: ames!vsi1!headland!jls
ARPA: jls%headla...@ames.nasa.arc.gov
I've always wished that the preprocessor had used modern language-design
principles and made undefined variables illegal rather than synonyms for
zero. Unfortunately there was a large body of code that depended on the
sloppiness, so now we're stuck with it.
The best we can hope for is to get compiler vendors to provide an option to
warn whenever an undefined symbol is used in a preprocessor conditional
(other than as the operand of defined(), of course). Then the next step
is to get software vendors to use "#if _S_UNIX" instead of "#ifdef _S_UNIX"
to test the compilation environment--that way, it becomes possible to
distinguish "symbol not set because this isn't UNIX" from "symbol not set
because that's not the name I use to flag what you're trying to test".
Karl W. Z. Heuer (ka...@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint
Example:
#ifdef MSDOS
do_dos_specific_stuff();
...
...
Hope it helps.
---
John Gordon
Internet: gor...@osiris.cso.uiuc.edu #include <disclaimer.h>
gor...@cerl.cecer.army.mil #include <clever_saying.h>
GEnie: j.gordon14
Two rules that can help with this and related problems are:
1. When enumerating values for a code, start at 1, not 0.
2. Make sure that if the user hasn't specified a choice (e.g. hasn't
defined one of several symbols tested with #ifdef, or hasn't
given a non-zero value to something tested with #if) that
the result is a complaint, not a default choice.
--
Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology
operating system. Now think about X. | he...@zoo.toronto.edu utzoo!henry
I'm not the one who asked about this in the first place, but I really
don't see how that would be expected to alleviate the situation. You
see, I recently encountered a bug of a similar character (heh), as
follows:
#define SYSV
{
...
#ifdef SYSY
...
#endif
...
}
In this situation, whether you use #if or #ifdef doesn't make any
difference. To exasperate the situation, I was using a terminal
upon which capital 'V's and 'Y's look even more similar than normal,
and the problem resulting from the #ifdef-ed code's absence only
manifested itself much later, in another module entirely separate
from the one where the bug was hiding.
That one took days, and large chunks of my hair, to find. B-(
I suppose that, if one is very concerned about this and is using
an ANSI-compliant preprocessor, one could do something like this:
#include <stdio.h>
#define SYSV 1
#define DOS 2
#define OSTYPE SYSV
main()
{
#if OSTYPE == SYSV
printf( "This is the System V-specific code.\n" );
#elif OSTYPE == DOS
printf( "This is the System V-specific code.\n" );
#else
#error OSTYPE undefined or mistyped
#endif
}
--
\\ David Sandberg \ ,=, ,=, \\
// d...@quad.sialis.mn.org / | |uadric '=,ystems //
\\ uunet!rosevax!sialis!quad!dts \ '=\ `=' \\