Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!haven!umd5!lgollub
From: lgollub@umd5.umd.edu (Lewis R. Gollub)
Newsgroups: comp.lang.c
Subject: Re: common bugs in C programs
Message-ID: <5860@umd5.umd.edu>
Date: 2 Jan 90 00:04:15 GMT
References: <61500001@uicbert.eecs.uic.edu>
Reply-To: lgollub@umd5.umd.edu (Lewis R. Gollub)
Organization: University of Maryland, College Park
Lines: 30

In article <61500001@uicbert.eecs.uic.edu> damerla@uicbert.eecs.uic.edu writes:
>
>I am compiling a list of syntax and logical errors I ever made while writing
>C programs.  Some of these errors are very simple but hard to debug like typing
>= in place of ==.  Till now I have compiled about 25 of them and any 
>contributions to this list will be appreciated.
>
>
     I am joining this thread rather late, but there is another solution
to this problem, outlined in an article in Byte, May 1986, by 
Peter Orlin and John Heath.

     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)
...

     This elegant (or inelegant, dependning on your sphistication and
your adherence to "standards") might help someone transferring to C
from Fortran, or with less programming background, and makes the prgogram
easier to read for a non-C programmer.

     Although  I don't code this way, I'd like to hear pro and con arguments
on this strategy.