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.

Nice post. But you forgot the single most common:
"My homework is due tomorrow please make it for me"

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!

Quote:

---

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.

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

Quote:

---

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.

Quote:

---

Originally Posted by MK27

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.

---

I find your analogy off for your own example. While this can be, indeed, the cause for off-by-one errors, it's not for the copying of strings. That is not caused by forgetting to add one after subtraction, but rather by forgetting to count \0 as a character that has to be stored as well. Still an off by one error, but different analogy.

Quote:

---

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.

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"

How about "if (x == 5 || 6) " instead of if (x == 5 || x == 6)or similar misunderstandings of logical operators? A variant would be something like "if (0 <= x <= 10)" for people more familiar with math than C syntax.

Quote:

---

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?

I cast mallocs because my C++ compiler, when Warning level is 4 (I think), would complain about mismatched type otherwise. I see no problem with casting malloc... as long as its prototype is included of course and it's not defaulting to int as mentioned above.

More common C problems encountered:

Semicolon follows "for" statement immediately... thereby making an empty loop. Hard to spot for newbies but I've seen this issue a few times now.

Confusion about int, long, long long and their maximum values allowable. Also difference between float and double, and corresponding formatting parameters for scanf, printf, etc.

Prudent use of global variables where needed. Review of stacked variables (are they called volatile, officially?) vs. use of the keyword "static".

Something a bit more general: lack of understanding of what "binary" file really is. I hate the term myself since every file (in fact everything) is binary anyhow. So let's reacquaint students with what "printable characters" are, new-line characters, etc. Just like back in the day we learned the ASCII chart.

Not strictly C but related: how to navigate through a directory/folder to access files. This problem seems to pop up often.

For casting return value of malloc(), it's not necessary.
There's no point to cast unless you are going to use C++ compiler.
But, I'd prefer

Code:

---

      foo_t *p;     
      p = malloc( sizeof(foo_t) );
      // prefer
      p = malloc( sizeof(*p) );

      #define NELEM(array)      ( sizeof(array) / sizeof( foo_t) )
      // prefer
      #define NELEM(array)      ( sizeof(array) / sizeof( (array)[0]) )

---

Quote:

---

Originally Posted by Bayint Naung

But, I'd prefer

Code:

---

      foo_t *p;
      p = malloc( sizeof(*p) );
      // prefer
      p = malloc( sizeof(foo_t) ); /* 1 */

      #define NELEM(array)      ( sizeof(array) / sizeof( foo_t) )
      // prefer
      #define NELEM(array)      ( sizeof(array) / sizeof( (array)[0]) ) /* 2 */

---

---

1. While it may be your preference, 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.

2. Neither of those methods work for arrays declared outside the current scope.


Quzah.

Quote:

---

Originally Posted by claudiu

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!".

---

I still remember one post.
" I compile this codel from online tutorial and my compiler gives error.
1.

Code:

---

for(int i = 0; i < n; i++) {       
...
}

---

The problem is most newbies don't know it's only supported in C99.
The worst thing is most will manage to write code that will compile.
2.

Code:

---

if( 0 < n < 10 ) {

---

But I find that gcc (if enable warning) will give warning.
1. compile with gcc -Wall foo.c
bar.c:100: error: ‘for’ loop initial declarations are only allowed in C99 mode
bar.c:100: note: use option -std=c99 or -std=gnu99 to compile your code

2. gcc -Wall foo.c
bar.c:106: warning: comparisons like ‘X<=Y<=Z’ do not have their mathematical meaning

Quote:

---

1. While it may be your preference, 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.

2. Neither of those methods work for arrays declared outside the current scope.

---

1. it's a misteaks! :D
2. YES