Programming With Integers - Programming Errors

Chapter chap2 section 11

`integer` rather than `int`

As with the earlier hello world program it is quite possible to make a variety of errors with the sum of 2 numbers programs. In the first example the programmer, possibly confused by another programming language has written integer rather than int .

main()
{
	integer	x,y;
	printf("Enter x ");
	scanf("%d",&x);
	printf("Enter y ");
	scanf("%d",&y);
	printf("The sum of x and y is %d\n",x+y);
}

This resulted in various error messages from the compilers. First the error messages produced by the IBM 6150 compiler.

"sum2.c", line 3: integer undefined
"sum2.c", line 3: syntax error
"sum2.c", line 5: x undefined
"sum2.c", line 7: y undefined

The following error messages were produced by the SUN Sparc Station compiler.

"sum2.c", line 3: integer undefined
"sum2.c", line 3: syntax error at or near variable name "x"
"sum2.c", line 5: x undefined
"sum2.c", line 7: y undefined
Compilation failed

And finally the following error messages were produced by the Turbo C compiler. These have been edited slightly by removing the file name that the Turbo C compiler puts at the start of each line.

3: Undefined symbol "integer" in function main
3: Statement missing ; in function main
5: Undefined symbol 'x' in function main
7: Undefined symbol 'y' in function main

A variable called `int`

In the next example the programmer tried to use two variables called int and inp . int is, of course, a keyword and, not surprisingly, the compilers gave various error messages.

main()
{
	integer	int,inp;
	printf("Enter int ");
	scanf("%d",&int);
	printf("Enter inp ");
	scanf("%d",&inp);
	printf("The sum of int and inp is %d\n",int+inp);
}

First the messages from the IBM 6150.

"sum2.c", line 3: illegal type combination
"sum2.c", line 3: syntax error
"sum2.c", line 5: syntax error
"sum2.c", line 8: syntax error

And now the SUN Sparc Station error messages.

"sum2.c", line 3: integer undefined
"sum2.c", line 3: syntax error at or near type word "int"
"sum2.c", line 5: syntax error at or near type word "int"
"sum2.c", line 7: inp undefined
"sum2.c", line 8: syntax error at or near type word "int"
Compilation failed

And finally the edited Turbo C error messages.

3: Too many types in declaration in function main
3: Need an identifier to delcare in function main
5: Expression syntax in function main
7: Undefined symbol 'inp' in function main
8: Expression syntax in function main

Confused variable names

In the next example the programmer has declared variables called n1 and n2 but has attempted to read into variables called x and y.

main()
{
	int	n1,n2;
	printf("Enter x ");
	scanf("%d",&x);
	printf("Enter y ");
	scanf("%d",&y);
	printf("The sum of x and y is %d\n",n1+n2);
}

This, not surprisingly, resulted in messages about undefined symbols. First from the IBM 6150.

"sum2.c", line 5: x undefined
"sum2.c", line 7: y undefined

Second, almost identically, from the SUN Sparc Station

"sum2.c", line 5: x undefined
"sum2.c", line 7: y undefined
Compilation failed

and finally from Turbo C

5: Undefined symbol 'x' in function main
7: Undefined symbol 'y' in function main

Misplaced declarations

In the next example the programmer has interleaved declarations and executable statements.

main()
{
	int	x;
	printf("Enter x ");
	scanf("%d",&x);
	int	y;
	printf("Enter y ");
	scanf("%d",&y);
	printf("The sum of x and y was %d\n",x+y);
}

This resulted in the following error messages from the IBM 6150 compiler

"sum2.c", line 6: syntax error
"sum2.c", line 8: y undefined

and the following from the SUN Sparc Station compiler

"sum2.c", line 6: syntax error at or near type word "int"
"sum2.c", line 8: y undefined
Compilation failed

Surprisingly the Turbo C compiler accepted the program without complaint and it worked quite happily and correctly. (See later notes on C++ ). The ANSI C standard does not sanction this sort of coding. Cases where compiler writers allow things that are not allowed by the published standard rules are called "extensions". If all your programs are always going to be compiled by the same compiler then there is no harm in using extensions and they are sometimes rather useful, so much so that they sometimes make their way into new published standards. However if you intend to publish your program in any way or anticipate it being moved from one computer system to another you must avoid such extensions at all costs.

Missing ampersands in scanf()

In the next example of a faulty program the programmer has left out the ampersands in the scanf() function calls.

/*	A program to read in two numbers
	and print their sum
*/
main()
{
	int	x,y;	/* places to store the numbers */
	printf("Enter x ");
	scanf("%d",x);
	printf("Enter y ");
	scanf("%d",y);
	printf("The sum of x and y was %d\n",x+y);
}

As was promised various varieties of chaos resulted. On all three systems the program compiled without any difficulty but attempts to run it had strange consequences. Both the IBM 6150 and the SUN Sparc Station produced the following dialogue.

$ sum2
Enter x 3
Memory fault - core dumped
$

ls -l command) revealed the following state of affairs on the SUN Sparc Station.

total 105
-rw-r--r--  1 jphb      8421808 Sep 23 14:47 core
-rwx------  1 jphb        24576 Sep 23 14:47 sum2
-rw-------  1 jphb          138 Sep 23 14:47 sum2.c

The effects on the IBM 6150 were similar but the file called core . was much smaller. The behaviour of Turbo C was quite different producing the following dialogue

Enter x 7
Enter y 6
The sum of x and y is 502
Null pointer assignment

To understand what has happened here it is necessary to remember that the values of the second and third parameters of scanf() are required to be the addresses of the locations that the converted numbers are stored in. In the C programming language the address of a memory location can always be obtained by proceeding its name with an ampersand. If the ampersand is omitted in the scanf() parameter list then the value passed to scanf() is not the address of "x" but the value that happened to be stored in "x", however the code of the scanf() library function knows nothing of this and assumes that the value it has received is an address and attempts to store the converted number in that memory location.

As was seen in an earlier example the initial value of "x" happened to be 0 on both the IBM 6150 and the SUN Sparc Station so, when scanf() had converted 3 to internal form it then attempted to store it in memory location 0. Unfortunately this memory location was clearly used for something else important and the over-writing of this important data has wrecked or, to use the jargon, crashed the program. The effects of such a crash depend very much on the particular compiler and host operating system.

On Unix systems the effect is that the "event" is detected or caught by the operating system which writes a program memory image to a file called, for historical reasons, core . There are various debugging tools which can be used to examine such core files in an attempt to find out what went wrong. Under MSDOS the effects are harder to predict depending on the particular compiler you are using, you may well have to re-boot the system.

The behaviour of the program compiled by the Turbo C compiler is particularly puzzling, after producing an incorrect answer it then produced a message that nobody other than a professional C programmer could reasonably be expected to understand. At least the Unix systems produced a message that a reasonable user could take to indicate that something has gone wrong.

Missing `printf()` parameters

The final example shows the interesting consequences of a piece of gross carelessness on the part of the programmer who has left out the "x+y" and the preceding comma in the final call to printf() in the sum of two numbers program. (I've done this myself more than once !)

main()
{
	int	x,y;
	printf("Enter x ");
	scanf("%d",&x);
	printf("Enter y ");
	scanf("%d",&y);
	printf("The sum of x and y was %d\n");
}

When this program was compiled and run on a SUN Sparc Station the result was

Enter x 3
Enter y 4
The sum of x and y was -134218272

The effect on the IBM 6150 was similar only the result was quoted as 536872196 and Turbo C gave the result 4.

The compiler did not generate any error messages on any of the systems, this is because, as far as the compiler is concerned, there is nothing wrong with the final printf(). The compiler does not check that the parameters after the format string match up with the conversion specifications included within the format string, the difficulty only shows up when the function printf() is executed.

This failure of C compilers to check that the parameters supplied to library function calls are consistent with the layout specification is unfortunate but almost universal. In the next chapter we shall see further examples of the consequences of such errors, it is important to recognise them.

What is happening is that, once printf() has determined, from the format string, that it needs an int , it expects one to have been provided in a standard place, unfortunately the correct number has not been stored in that standard place.

Keyword List