469,300 Members | 2,352 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Share your developer knowledge by writing an article on Bytes.

Ten common C (silly) mistakes

13,262 8TB
There are a lot of common C mistakes. I have put together the ones I consider to be the silliest made by C programmers. These are usually the source of the popular C programming tears and remembering the items on this page will brighten your C programming days somewhat.

(1) Values returned by mathematical functions on domain errors are implementation defined.

The best way of handling such domain errors is to ensure that they never arise at all. e.g Test for positive value before taking square root. Assuming that the compiler will return a certain value when the number is negative is a silly mistake.

(2) The minimum guaranteed value for the char type is zero.

This means that it is up to the implementation to have chars behaving as signed or unsigned char. To obtain the minimum value for your chars use CHAR_MIN defined in limits.h.

(3) Side effects are also silly

It is unsafe to use the same variable more than once in an expression if evaluating that expression changes the variable and the new value could affect the result of the expression.
Be careful when writing long expressions involving increment/decrement operators or expressions which call functions by reference.
Even x = x++; is unsafe.

(4) Don't skip the precedence tables.

Precedence tables are often skipped by people when reading introductory books but sometimes they can come back and smack you with the silly tag. If you miss that == (and !=) have higher precedence than ?: then you might expect c = (1?0:1 == 1?0:1); to assign the value 1 to c. Your reasoning would probably be that whatever is to the left of == is the same as what is to its right so the result should be true and c be one. That kind of reasoning is of course quite silly. The precedence table shows that the expression is evaluated as c = (1?0:(1 == 1)?0:1); with the inner brackets evaluated first then from left to right leaving c with a value of 0.
Association is also important e.g while ++ and * have equal precedence, they associate right to left meaning that *p++ will be evaluated as *(p++).

(5) Always use function prototypes.

If you don't then they are assumed to be taking the default type which is int. You might start to think that if you know the defaults then you should be able to assume them and not have to explicitly specify them. Those are very silly thoughts and should be immediately dismissed from the mind. Also cast any function arguments to the expected type if they are not that type already.

(6) The order of evaluation of function arguments is not defined.

That means that in

Expand|Select|Wrap|Line Numbers
  1. int a () {
  2.   printf("a\n");
  3.   return 1;
  4. }
  5. int b () {
  6.   printf("b\n");
  7.   return 2;
  8. }
  9. int c () {
  10.   printf("c\n");
  11.   return 3;
  12. }
  13. int sum (int a, int b, int c) {
  14.   return a + b + c;
  15. }
  16. int main(int argc, char** argv) {
  17.   printf("%d", sum(a(), b(), c()));
  18.   return (EXIT_SUCCESS);
  19. }

the only guaranteed output is 6 (the sum) not the order in which a,b or c are printed.

(7) sizeof pointer to type T is the size of only one T element.

In particular, in

Expand|Select|Wrap|Line Numbers
  1. T arr[10];
  2. T *p = arr;
sizeof(*p) != sizeof(arr). Rather sizeof(arr) = 10 * the size of one T element while sizeof(*p) is only the size of one T element.
The size of sizeof is also implementation defined and size_t (defined in stdlib.h) or unsigned long should be used to hold its value.

(8) main must return an int.

You don't call main in your programs, do you? So who calls it? How does he know how you have defined your main if he is calling it? The answers are simple. The guy who calls your main assumes that your main returns an int. Usually the caller will use that returned value to determine the success status of the program. If you don't give him that, he is going to get garbage and use that for whatever reed dancing he does with the returned value.

(9) Mixing signed and unsigned types with closed eyes.

The man who declares an unsigned type must slap himself awake every time he uses it in an expression with other types. Indeed anyone who writes any expression involving mixed types must be on guard. The stories about goblins lurking around programs collecting bits from expression evaluations are true and should not be deemed as silly.

(10) Array bounds. Need I say more?

If any of your functions take an array as argument, then pass that array's length as well. Avoid any functions which accept an array without also taking its length. In particular never use gets().
Nov 5 '08 #1
10 60750
Eleventh one could be using = in place of == .
Feb 23 '09 #2
Why aren't they numbered 0-9? Then you could fit in =/==. Oh that would be eleven mistakes. Ooops. Anyone for Spinal Tap?
Mar 28 '09 #3
@freelance programmer
To avoid this logical mistake while making comparison, use constant on the left hand and the variable on the right. i-e if u want to compare x and 2;

Expand|Select|Wrap|Line Numbers
  1. if(x == 2)
  2. ...
will obviously work but to be on safe side, write
Expand|Select|Wrap|Line Numbers
  1. if(2 == x)
  2. ...
By doing so, your otherwise logical error by using '=' instead of '==' will be caught.
Expand|Select|Wrap|Line Numbers
  1. if(2 = x)
  2. ...

Mar 30 '09 #4
The size of a pointer to type T is the size of a pointer. The size of the type pointed to is irrelevant.
May 13 '09 #5
Yes, and the size of pointer (to whatever) is equal to the size of an int.
May 14 '09 #6
That may be the case for a particular implementation but it isn't true in general.

The size of an int is implementation dependant but is at least 16 bits.

The size of a pointer is implementation dependent. It's possible that pointers to different types have different sizes.
May 14 '09 #7
Now compiler gives a warning for
Expand|Select|Wrap|Line Numbers
  1. if(x = 2)
but most programmers ignore them
Jun 3 '09 #8
As per the 9th commandment, can someone explain why the below line gets printed

unsigned int i = 5;
int j = -20;

if(i+j > 5)
printf(">5=%d\n",i+j); //why this gets printed
Sep 2 '09 #9
2,422 Expert 2GB
I must be one a consequence of the integer promotion rules when you have an expression involving an unsigned int and a signed int. It looks like the rule must be to evaluate that expression using unsigned arithmetic. My copy of the Standard isn't handy so I can't confirm that.
Sep 2 '09 #10
yes i believe thats the right answer. Thank you
Sep 3 '09 #11

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

53 posts views Thread by KraftDiner | last post: by
9 posts views Thread by bwaichu | last post: by
reply views Thread by pagates | last post: by
2 posts views Thread by rdemyan via AccessMonster.com | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Geralt96 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.