Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!hstbme.mit.edu!scs
From: scs@hstbme.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: Atomic #defines (was Re: Password checking program)
Message-ID: <13899@bloom-beacon.MIT.EDU>
Date: 29 Aug 89 05:50:38 GMT
References: <15257@duke.cs.duke.edu> <652@lakart.UUCP> <10765@smoke.BRL.MIL> <1625@mcgill-vision.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 38

In article <1625@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes:
>In article <10765@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>> In article <13569@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes:
>>>	#define ERROR (EOF-1)
>> Don't do this.  You don't know what EOF might be defined as, so this
>> might not work right.
>Then as far as I can see there is *no* way to (portably) choose an int
>value which is not EOF and not a valid char.  Anything I can do, as far
>as I can see, will... either overflow, re-use the value of EOF,
>or re-use the value of some char.

Sure there is:

	#if EOF != -2
	#define ERROR (-2)
	#else
	#define ERROR (-3)
	#endif

The only reason I didn't do this in the program that prompted the
original complaint was that I didn't want to require that
<stdio.h> be #included before the header file that was trying to
#define ERROR.  (I can't yet depend on ANSI's guarantee that
multiple #inclusions of standard header files are safe, so I
didn't have the header file in question #include <stdio.h>
itself.  It occurs to me that

	#ifndef EOF
	#include <stdio.h>
	#endif

is probably a safe way to protect against a non-idempotent
<stdio.h>.  I used to occasionally cheat and use #ifndef FILE for
this purpose, but FILE isn't necessarily a preprocesser macro and
should probably be a typedef instead.  But EOF is required to be
a macro, right?)

                                                     Steve Summit