common bugs in C programs

Matthew Waugh waugh at dg-rtp.dg.com
Fri Jan 5 08:34:55 AEST 1990


In article <1990Jan3.095204.6979 at gdt.bath.ac.uk> exspes at gdr.bath.ac.uk (P E Smee) writes:
>In article <5860 at umd5.umd.edu> lgollub at umd5.umd.edu (Lewis R. Gollub) writes:
>>     They propose using the preprocessor to define various substitutions
>>of standard C code for more easily read programmer's code.
>>     In this case you would include a line
>>
>>#define EQ ==
>>      if (a EQ b)
>>
>I keep a copy of their 'easy_c.h' lying around as an example of what
>the preprocessor can do, but I don't actually approve of the use of
>this technique.  While it can make reading the code easier for the
>person who is accustomed to using it, it suffers from several
>shortcomings, which are in my opinion fairly major.


I once had the "privilege" of working with someone who successfully,
via the use of the pre-processor, turned C into Pascal, including
such fascinating additions as

#define		then	
#define		do
#define		begin	{
#define		end	}

I personally hated it, but I used to take a perverse delight in
generating programs that would either completly blow out of
the water with wierd and wonderful error messages due to these
translations, or inter-mix C and "pseudo-Pascal" to produce
programs with a truly awful readability factor.

Ho Hum, to each his/her own I guess.

Mat

------------------------------------------------------------------------
Matthew Waugh			waugh at dg-rtp.dg.com
RTP Network Services 		{world}!mcnc!rti!dg-rtp!waugh
Data General Corp.		
RTP, NC. (919)-248-6344



More information about the Comp.lang.c mailing list