Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!tut.cis.ohio-state.edu!unmvax!bbx!bbxsda!scott
From: scott@bbxsda.UUCP (Scott Amspoker)
Newsgroups: comp.lang.c
Subject: Re: Redefining keywords (was Re: effect of free()
Message-ID: <110@bbxsda.UUCP>
Date: 19 Sep 89 15:37:16 GMT
References: <254@bbxeng.UUCP> <10829@riks.csl.sony.co.jp> <102@bbxsda.UUCP> <14694@bfmny0.UU.NET>
Reply-To: scott@.UUCP (Scott Amspoker)
Organization: /etc/organization
Lines: 34

In article <14694@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes:
 >
 >	#ifdef I86
 >	#define NEAR near
 >	#define FAR far
 >	#else
 >	#define NEAR
 >	#define FAR
 >	#endif
 >

That is exactly what we ended up doing after we discovered that
'#define near' would not work on one compiler.

The point I was making was that up until this one compiler came
along there was no problem.  Compilers that don't support near/far
typically don't recognize them as special words anyway.  So here we
have a case of one compiler that sticks out like a sore thumb.  Somebody
mentioned once in the group about the "principle of least astonishment".
It just never occured to us that:

   A.  A compiler on an architecture that has no concept of near/far
       would consider near/far meaningful.

   B.  The preprocessor would care at all about anything other than
       it's own instructions.

So we simply changed near to NEAR and far to FAR.  Now that we are
typing 'near' and 'far' in uppercase we are no longer being lazy (asshole!).

-- 
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232