Thread: Most Common problems in C

I'd like to make a list of most common problems that newbies to C are facing and possible solutions.
I'll start with:

Problems

1. fflush(stdin)
2. scanf() leaves newline ( related to 1 )
3. void main(void) vs int main(void)
4. not initializing variable before use
5. pointer vs array
6. scanf("%s",&array_name) ;
7. misplacing equality operator( == ) with assignment operator (=)

Code:

    if( i   =   1 )   {       /* trouble! */ 
     if( 0 < n < 10 )  instead of if( n > 0 && n < 10)
     if (x == 5 || 6)  instead of  if (x == 5 || x == 6)

8. Off by One Error ( by Mk27)

Code:

 
     char *copy = malloc(strlen(string));       /* forget +1 for null char*/
     strcpy(copy,string);

9.

Code:

  
       foo_t *p;

       p = malloc( sizeof(*p) );          // good practice 
       
       p = malloc( sizeof(foo_t) );

Solutions

1. fflush(stdin)
2. same as 1
3. void main(void) vs int main(void)
4. Enable compiler warning (for gcc, use -Wall flag)
5. pointer vs array
6. scanf("%s",&array_name);
7. Enable compiler warning.
8.
9. The former method is less accident prone, and is easier to maintain (ie: you don't have to ever change it). If you go back and substitute foo_t for bar_t, you have to chase down all of your malloc calls, and change them too. If you use the first method, you don't have to. ( By quzah )

Please feel free to add other problems you could think of.

Your intention is nice but don't forget that the ignorance of posters that EVOEx describes above is greater than any FAQ, or compilation of issues you can come up with. All of these issues are addressed on the FAQ, there are numerous stickies and pointers when you register as to read them however, they are ignored. I am afraid your post will suffer the same treatment unfortunately.

That is a pretty good list. Altho it's not C specific, I'd add the "off by one" (aka, fencepost) errors:

Off-by-one error - Wikipedia, the free encyclopedia

which are very easy for beginners in particular to make. Having a name for this one (OBOE or fencepost) is good because once you know the name it is more likely to occur to you as a possibility where appropriate (or at least spot once it's happened). There are some common C specific situations involving the null terminator on strings -- eg:

Code:

char *copy = malloc(strlen(string));
strcpy(copy,string);

Off by one overflow!

Originally Posted by claudiu

I am afraid your post will suffer the same treatment unfortunately.

Maybe, but Bayint Naung has hit on some very common issues that probably cannot be repeated too many times. It would not be a bad idea to refer to someone who has made one of them to a "top 10" list the first time. For every person that ignores that kind of thing, I bet there are more that actually take an interest and even learn something -- just you won't be hearing from them.

Originally Posted by Bayint Naung

@ MK27, I forgot that! How to avoid Off by One error?! Count carefully?

I guess. I would say that for allocation, too much is better than too little, but that is not true for iterative reads, so not very good advice. Seems to me that once I read the analogy (you need 11, not 10 fenceposts for a 100' fence with posts every 10 feet) it was easier to conceive of and notice.

Originally Posted by EVOEx

I find your analogy off for your own example.

Technically, I wasn't using that analogy with that example, they were in two separate posts.

You're right, tho, understanding the fencepost error may or may not help with the strlen one in the strict sense of the fencepost analogy being about inclusion in a series (0-10 is eleven numbers).

On the other hand, it is still conceptually similar -- when you get to the tenth pole, you'll notice there's still a unit of fence left unaccounted for, altho in this case it has to do with a C specific issue (what strlen counts and what a C string is) as opposed to a plain old arithmetic error.

Well, fueled by MK27's relentless optimism I decided it's time to drop the skepticism and add my own thing here. One thing I see here everyday and is driving me nutz, although not a mistake per say is the casting of malloc().

Another thing, which is not necessarily related to C is the confusion between an IDE and a compiler. Most people will come and say... "ohh I compilez my codez with Eclipse and needz helpz cuz deadline iz tomorrow!".

It's not really an error to cast mallocs return type, it's just unnecessary in C.

Originally Posted by stabu

claudiu you must'nt have any hair left, because casting malloc seems to be the dominant style in alot of code I, at least, need to analyse.

Hell, I even do it, so nobody looks askance at my code.

The confidence to not cast your mallocs, must be the sign of an advanced coder, I reckon.

Of course people say, "oh, it's just to make my code clearer", oh yeah, right .. the logic being "if I cast my mallocs, I can claim to write clear code, the rest can remain unclear"

As the poster above mentioned casting malloc in C is not a problem of confidence. It is totally useless. In fact, it can even prove dangerous if you don't include stdlib because then the function will be assumed to return an int. If ints and pointers are of different sizes on your machine, you may be in for a run-time surprise. The code you are looking at is probably compiled with a C++ compiler. I feel like most people compiling with gcc or other C compilers cast malloc BECAUSE they don't really understand the reason why they don't need to cast it.

Let me add something:
Considering that your posts cannot be edited after some time, and that noone wants to read through a thread with 1000X posts, and read lots of replies that aren't relevant to them, how about just summarizing it all in a page that has already begun? Like, for example, SourceForge.net: Common mistakes and errors - cpwiki?