Determining C Complexity

[Walter Bright]

In article <161 at srchtec.UUCP> johnb at srchtec.UUCP (John Baldwin) writes:
<In article <2600 at dataio.Data-IO.COM> bright at Data-IO.COM (Walter Bright) writes:
<|Some things they look for:
<|	o Array fencepost problems
<|	o Possible array overflows
<|	o Portability problems
<|	o Inefficient code	(i & 1) ? 1 : 0
<|	o Dead code
<All of the above are good candidates for automation: they can be detected
<just as easily using "mechanical" methods.

True, simple cases can be discovered by automation. Most cases I worry about
that *cannot* be (and I've seen all of these):

o Array fencepost problems
	func(char *p)
	{	for (i = 0; i <= max; i++)	/* ERROR! should be i < max */
			p[i] = 5;
	}

o Possible array overflows
	char a[10];
	strcpy(a,p);		/* is p guaranteed to fit?	*/

o Portability problems
	Not fopen'ing a binary file with "rb" instead of "r".

o Inefficient code
	Replacing a bubble sort with qsort().
	Replacing scaling by a double with scaling by a long.

o Dead code (typically there due to maintenance, the case may be handled
  elsewhere in the program or may have been designed out of existence)
	switch (i)
	{	case 1:  ....
		case 2:  ....
		case 3:  ....	/* but i can never be 3 in this function! */
	}

The possibilities, of course, are endless. An analysis program simply
cannot know what the design of the program is supposed to be.