damerla@uicbert.eecs.uic.edu (12/22/89)
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. Srini
bright@Data-IO.COM (Walter Bright) (12/23/89)
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.
Andy Koenig has already done a fine job of this and published it in a book
"C Traps and Pitfalls".amull@Morgan.COM (Andrew P. Mullhaupt) (12/24/89)
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. It would seem that I have to go through all the C source you ever wrote to contribute to your list. Would you be interested in errors that other people have made instead? Later, Andrew Mullhaupt
Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) (12/24/89)
In an article of <22 Dec 89 03:33:00 GMT>, 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. If you make it a matter of style to write conditionals as (const == var) rather than (var == const), your compiler will flag the error for you and make your code *much* easier to debug.
nevin1@cbnewsc.ATT.COM (nevin.j.liber) (12/27/89)
In article <7140.25959377@urchin.fidonet.org> Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) writes: > >If you make it a matter of style to write conditionals as (const == var) >rather than (var == const), your compiler will flag the error for you and make >your code *much* easier to debug. Also, just by using (var == const) instead of (const == var), you tend not to make the mistake at all. -- _ __ NEVIN ":-)" LIBER nevin1@ihlpb.ATT.COM (708) 979-4751 IH 4J-323 ' ) ) "We are almost into the '90s; *nothing* is weird." / / _ , __o ____ -- Buzz Kelman, Newsman & Bluesman, WLUP, 7/28/89 / (_</_\/ <__/ / <_ As far as I know, these are NOT the opinions of AT&T.
norm@oglvee.UUCP (Norman Joseph) (12/27/89)
From article <61500001@uicbert.eecs.uic.edu>, by damerla@uicbert.eecs.uic.edu: > > 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. You may want to save yourself some time and effort and check your favorite bookstore for _C Traps and Pitfalls_, by Andrew Koenig, Addison-Wesley 1989, ISBN # 0-201-17928-8. This book is exactly the list of syntax & logical errors you are trying to compile, along with explanations and advice. -- Norm Joseph - Oglevee Computer System, Inc. UUCP: ...!{pitt,cgh}!amanue!oglvee!norm /* you are not expected to understand this */
ted@ultra.com (Ted Schroeder) (12/29/89)
Bob.Stout@p6.f506.n106.z1.fidonet.org (Bob Stout) writes: >In an article of <22 Dec 89 03:33:00 GMT>, 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. >If you make it a matter of style to write conditionals as (const == var) >rather than (var == const), your compiler will flag the error for you and make >your code *much* easier to debug. Ah, but how ugly the code becomes. There are few things that are more annoying to me than to have a piece of code assert if (2 == x) return; 2 does not equal something, but something may in fact be equal to 2. Ted Schroeder ted@Ultra.com Ultra Network Technologies ...!ames!ultra!ted 101 Daggett Drive San Jose, CA 95134 408-922-0100 Disclaimer: I don't even believe what I say, why should my company?
roy@phri.nyu.edu (Roy Smith) (12/29/89)
In <1989Dec28.200433.16824@ultra.com> ted@ultra.com (Ted Schroeder) writes: > 2 does not equal something, but something may in fact be equal to 2. "2 does not equal 3. Not even for very large values of 2." -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy "My karma ran over my dogma"
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (01/02/90)
In article <523@oglvee.UUCP> norm@oglvee.UUCP (Norman Joseph) writes: | From article <61500001@uicbert.eecs.uic.edu>, by damerla@uicbert.eecs.uic.edu: | > | > 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. When developing the IMP language from B, along with other changes I used = for equality, := for assignment, and <> for not equal. This was strongly influenced by the widespread use of Algol60 at that time, but the people who helped me design changes agreed that these were readability improvements. Oddly, the change from =+ to += never went in, and the language is dead now. -- bill davidsen - sysop *IX BBS and Public Access UNIX davidsen@sixhub.uucp ...!uunet!crdgw1!sixhub!davidsen "Getting old is bad, but it beats the hell out of the alternative" -anon
lgollub@umd5.umd.edu (Lewis R. Gollub) (01/02/90)
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.
exspes@gdr.bath.ac.uk (P E Smee) (01/03/90)
In article <523@oglvee.UUCP> norm@oglvee.UUCP (Norman Joseph) writes: >You may want to save yourself some time and effort and check your favorite >bookstore for _C Traps and Pitfalls_, by Andrew Koenig, Addison-Wesley 1989, >ISBN # 0-201-17928-8. This book is exactly the list of syntax & logical errors >you are trying to compile, along with explanations and advice. A good book. It didn't actually list any 'pitfalls' that I wasn't already aware of, but some of his methods of avoidance were new. Besides, it's full of the sort of stuff that even if you already know it, it doesn't hurt to remind yourself of from time to time. Besides, I liked the author's credit on the cover. To the effect that 'more recently, Andrew Koenig implemented a software maintenance system that allows an administrator to crash dozens of systems with a single command.' -- Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132 Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)
exspes@gdr.bath.ac.uk (P E Smee) (01/03/90)
In article <5860@umd5.umd.edu> lgollub@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) > > 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. 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. First, it makes the code much harder to read for people who DON'T use this approach -- like, probably, whoever takes over maintenance of your code. Second, it keeps the user of the technique from becoming familiar with 'raw' C, and so makes it harder for them to take over code belonging to other people. And, third (but contributing to both of those) some of the constructs they provide have the effect of changing the APPARENT syntax of the language, so providing room for confusion. -- Paul Smee, Univ of Bristol Comp Centre, Bristol BS8 1TW, Tel +44 272 303132 Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you MUST)
waugh@dg-rtp.dg.com (Matthew Waugh) (01/05/90)
In article <1990Jan3.095204.6979@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee) writes: >In article <5860@umd5.umd.edu> lgollub@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@dg-rtp.dg.com RTP Network Services {world}!mcnc!rti!dg-rtp!waugh Data General Corp. RTP, NC. (919)-248-6344
malkie@hpqtdla.HP.COM (Malcolm Rix) (01/08/90)
Here is a list of things we found to be common mistakes programmers made here
at QTD - some of them are general programming errors rather than specific to
C
/V\alkie
===============================================================================
As we all know 'C' is a language riddled with potential problems and
pitfalls for the unwary. While developing code and reviewing the work of others
in the common firmware group we have been collecting a list of the most
frequent problems:
(1) Misinterpretation of number bases (i.e. 0x12 != 12 or 0x01000 != 8).
(2) Loop initialisers are placed within the loop.
(3) Problems releating to undeclared extern functions or parameters defaulting
to type 'int'.
(4) Float constants present in code without '.' or 'E' in the number.
(5) Misinterpretation of the conversion processes in mixed type expressions.
(esp. Where 'int', 'float' and 'double' are combined.)
(6) Forgetting equality test is '==' rather than '=' (a common error for ex.
PASCAL programmers).
(7) Leaving '&' off variable parameters to functions.
I.e. Writing 'scanf("%d\n", i);' rather than 'scanf("%d\n", &i);'.
(8) Uninitailised variables getting forgotton due to side effects of RAM tests.
(It is a good idea to set the memory to a range of values before testing).
(9) Calling a function with the wrong number of parameters.
(10) Calling a function with the wrong type of parameters.
(11) Confusing '&' and '&&' in boolean expressions.
(12) Using /* in an expression and accidently starting a comment.
E.g. x = 3/*i;
(13) Ommitting 'const' from ROM data.
(14) Assuming x<<2 is the same as x*2. (Its actually x<<1).
(15) Substituting shifts for multiplies by powers of 2 in expressions
without taking taking care of change in operator precedence.
The expression: y = x*2 + 4;
Should be rewritten: y = (x<<1) + 4;
And not: y = x<<1 +4;
(16) Passing structures to functions as if they were arrays and assuming a
pointer is passed (it is not, the struct is passed as a value parameter).
(17) Comparison of floats for equality.
(18) Finishing a "for( init;conditional; command)" statement with a semicolon.
(19) Forgetting to declare space for variable length string within list
elements.
(20) Missing a semicolon off a typedef statement.
(21) Putting a semicolon on a #define statement.
(22) Getting complex declarations wrong - e.g. A pointer to an array of
pointers to functions returning pointer to float etc.
(23) Forgetting *(a+i) is the same as a[i] so that *(a+10) doesn't access
the 11th byte of `a' but the eleventh entry in an array of structures.
(24) Forgetting address arithmetic is done in multiples of the size of
the objects to which the pointers point.
I.e: int *a; a++; /* Points to next WORD not next BYTE */
(25) Confusing (a.b) and (a->b).
(26) Misunderstanding dereferencing of things like *(a->b).
Malkie
Ranascott@bbxsda.UUCP (Scott Amspoker) (01/09/90)
In article <430009@hpqtdla.HP.COM> malkie@hpqtdla.HP.COM (Malcolm Rix) writes: > While developing code and reviewing the work of others >in the common firmware group we have been collecting a list of the most >frequent problems: >[list deleted] one of my favorites: i = (getchar()<<8) + getchar(); The evaluation order is not guaranteed. A similar thing can happen with function arguments. should be: i = getchar()<<8; i += getchar(); -- Scott Amspoker Basis International, Albuquerque, NM (505) 345-5232 unmvax.cs.unm.edu!bbx!bbxsda!scott
hascall@cs.iastate.edu (John Hascall) (01/10/90)
In article <430009@hpqtdla.HP.COM> malkie@hpqtdla.HP.COM (Malcolm Rix) writes: }As we all know 'C' is a language riddled with potential problems and }pitfalls for the unwary. While developing code and reviewing the work of others }in the common firmware group we have been collecting a list of the most }frequent problems: }(14) Assuming x<<2 is the same as x*2. (Its actually x<<1). }(15) Substituting shifts for multiplies by powers of 2 in expressions } without taking taking care of change in operator precedence. also be very careful with >> as a low-budget divide }(24) Forgetting address arithmetic is done in multiples of the size of } the objects to which the pointers point. } I.e: int *a; a++; /* Points to next WORD not next BYTE */ ^^^^ may not be a WORD!! John Hascall / ISU Comp Ctr
hawk@hpavla.AVO.HP.COM (Dave Hawk) (01/18/90)
>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. Any bets on which of these 25 took down AT&T the other day?
roland@cochise.pcs.com (Roland Rambau) (02/02/90)
malkie@hpqtdla.HP.COM (Malcolm Rix) writes:
->in the common firmware group we have been collecting a list of the most
->frequent problems:
->(1) Misinterpretation of number bases (i.e. 0x12 != 12 or 0x01000 != 8).
....
->(26) Misunderstanding dereferencing of things like *(a->b).
my favorite :-) selfmade error:
(n+1) Not declaring an external float function as extern _float_ when the
returned value is never used ( this doesn't matter e.g. on the vax,
but yields a bogus stack when porting e.g. to the apollo :-)
I know that You believe You understand what You think I said, but
I'm not sure You realize that what You heard is not what I meant.
Roland Rambau
rra@cochise.pcs.com, {unido|pyramid}!pcsbst!rra, 2:507/414.2.fidonet
I know that You believe You understand what You think I said, but
I'm not sure You realize that what You heard is not what I meant.
Roland Rambau