Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.lang.c
Subject: Re: Atomic #defines (was Re: Password checking program)
Message-ID: <1625@mcgill-vision.UUCP>
Date: 28 Aug 89 08:32:11 GMT
References: <15257@duke.cs.duke.edu> <652@lakart.UUCP> <10765@smoke.BRL.MIL>
Organization: McGill University, Montreal
Lines: 26

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 (for some choice of EOF, int range, and char range)
either overflow, re-use the value of EOF, or re-use the value of some
char.

> EOF belongs to the C implementation.  Invent your own symbols for
> your own uses.

Fine.  But how?

By the way, it seems to me that the required existence of EOF implies
that it is not a legal implementation choice to make char and int
identical.  Is this true?  (Flame retardant: I didn't say "sane", I
said "legal".)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu