Path: utzoo!attcan!uunet!cs.utexas.edu!usc!bloom-beacon!adam.pika.mit.edu!scs From: scs@adam.pika.mit.edu (Steve Summit) Newsgroups: comp.lang.c Subject: Re: Atomic #defines (was Re: Password checking program) Message-ID: <13569@bloom-beacon.MIT.EDU> Date: 17 Aug 89 04:22:22 GMT References: <15257@duke.cs.duke.edu> <652@lakart.UUCP> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: scs@adam.pika.mit.edu (Steve Summit) Lines: 30 In article <652@lakart.UUCP> dg@lakart.UUCP (David Goodenough) writes: >1. Use, and EOF, because there are no guarantees that EOF has to be > -1: I could use -42 if the spirit so moved me. Is this true? Harbison and Steele (not necessarily a definitive pANS reference, I know) imply that it is always -1; at least, their discussion (p. 311 in the second edition) includes the example line #define EOF (-1) I agree that depending on the value is a bad idea, but it can be easy to write code which does so. One way is to start defining your own error codes which might be returned, along with EOF, from some intermediate-level input routines: #define ERROR (-2) A better way (which is portable as long as you know that all successful returns are positive) is #define ERROR (EOF-1) The only trouble here is that the header file in which you #define ERROR then ought to #include , but that isn't necessarily a good idea under old implementations... Steve Summit scs@adam.pika.mit.edu