Redefining keywords (was Re: effect of free()

Scott Amspoker scott at bbxsda.UUCP
Wed Sep 20 01:37:16 AEST 1989


In article <14694 at bfmny0.UU.NET> tneff at 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



More information about the Comp.lang.c mailing list