Industrial Training

C Program



C Programmers are great innovators of our times. Unhappily, among their most enduring accomplishment are several new techniques for wasting time. There is no shortage of horror stories about programs that took twenty times to 'debug' as they did to 'write'. And one hears again and again about programs that had to be rewritten all over again because the bugs present in it could not be located.
A typical C programmer's morning after is red eyes, blue face and a pile of crumpled printouts and dozens of reference book all over the floor. Bugs are C programmer's birth right. But how do we chase them away. No sure-shot way for that. I thought if I make a list of more common programming mistakes it might be of help. They are not arranged in any particular order. But as you would realize surely a great help!

  1. Omitting the ampersand before the variables used in scanf(  ).

For example,
int choice ;
scanf ( " %d ", choice ) ;
 
Here, the & before the variable choice is missing. Another common mistake with scanf( ) is to use blanks either just before the format string or immediately after the format string as in,
int  choice ;
scanf ( " %d ", choice ) ;
 
Note that this is not a mistake, but till you don't understand scanf( ) thoroughly, this is going to cause trouble. Safety is in eliminating the blanks. Thus, the correct from would be,
int choice ;
scanf ( " %d ", &choice ) ;

  1. Using the operator = instead of the operator ==.

What do you think will be the output of the following program:
main( )
{
int i = 10 ;
while ( i = 10 )
{
printf ( "got to get out" ) ;
i++ ;
}
}
 
At first glance it appears that the message will be printed once and the control will come out of the loop since i becomes 11. But, actually we have fallen in an indefinite loop. This is because the = used in the condition always assigns the value 10 to i, and since i is non-zero the condition is satisfied and the body of the loop is executed over and over again.

  1. Ending a loop with a semicolon. Observe the following program.

main(  )
{
int j = 1 ;
while ( j <= 100 ) ;
{
printf ( "\nCompguard" ) ;
j++ ;
}
}
 
Inadvertently, we have fallen in an indefinite loop. Cause is the semicolon after while. This in effect makes the compiler feel that you wanted the loop to work in the following manner:
while ( j <= 100 ) ;
 
By all means an indefinite loop since j never gets incremented and hence eternally remains less that 100.

  1. Omitting the break statement at the end of a case in a switch statement. Remember that if a break is

not included at the end of a case then execution will continue into the next case.
 
main( )
{
int ch = 1 ;
switch ( ch )
{
case1 :
printf ( "\nGoodBye" ) ;
 
case 2 :
printf ( "\nLieutenant" ) ;
}
}
 
Here, since the break has not been given after the printf( ) in case 1, the control runs into case 2 and executes the second printf( ) as well. However, this sometimes turns out to be a blessing in disguise, especially, in cases when we are checking whether the values of a variable equals a capital letter or a small case letter.

  1. Using continue in a switch. It is a common error to believe that the way the keyword break is used with while, for, do-while and a switch, similarly the keyword continue can also be used with them. Remember, continue works only in loop, never with a switch.
  2. A mismatch in the number, type and order of actual and formal argument.

yr= romanise ( year, 1000, 'm' ) ;
 
Here, three arguments in the order int, int and char are being passed to romanise( ). When romanise( ) receives these arguments they must be received in the same order by the formal arguments. A careless mismatch might give strange results.

  1. Omitting provisions for returning non-integer value from a function.

If we make the following function call, 
area = area_circle ( 1.5 ) ;
 
then while defining area_circle( ) function later in the program, care should be taken to make it capable of returning a floating point value. Note that unless otherwise mentioned, the compiler will assume that function returns a value of the type int.

  1. Inserting a semicolon at the end of a macro definition. How do you recognize a C programmer? Ask him to write a paragraph in English and watch whether he ends each sentence with a semicolon. This usually happens because a C programmer becomes habitual to ending all statements with a semicolon. However, a semicolon at the end of a macro definition might create a problem.

For example,
#define UPPER 25;
 
would lead to a syntax error if used in an expression such as 
if ( counter == UPPER )
 
This is because on preprocessing the if statement would take the form
if ( counter == UPPER; )

  1. Omitting parentheses around a macro expansion.

#define SQR(x) x*x
main( )
{
int a ;
a=25 / SQR ( 5 ) ;
printf ( "\n%d", a ) ;
}
 
In this example we expect the value of a to be 1, whereas it turns out to be 25. This so happens because on
preprocessing the arithmetic statement takes the following form:
a = 25 / 5 * 5 ;

  1. Leaving a blank between the macro template and the macro expansion.

#define ABS (a) ( a=0 ? a : -a )
 
Here, the space between ABS and (a) makes the preprocessor believe that you want to expand ABS into (a), which is certainly not what we want.

  1. Using an expression that has side effects in a macro call.

#define SUM(a) (a+a)
main( )
{
int w, b = 5;
w= SUM ( b++ ) ;
printf ( "\n%d", w ) ;
}
On preprocessing the macro would be expanded to, w=(b++) +(b++); If you are wanting to first get sum 5 and 5 and them increment b to 6, that would not happen using the above macro definition.

  1. Confusing a character constant and a character string

In the statement
ch = 'z';
 
a single characters is assigned to ch. In the statement
ch = "z"
a pointer to the characters string "a" is assigned to ch.
 
Note that in the first case, the declaration of ch would be,
char ch ;
 
whereas in the second case it would be,
char*ch;

Hi I am Pluto.