Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!entropy!dataio!bright
From: bright@Data-IO.COM (Walter Bright)
Newsgroups: comp.lang.c
Subject: Re: Determining C Complexity
Keywords: C, complexity, metrics, cyclomatic complexity, McCabe
Message-ID: <2611@dataio.Data-IO.COM>
Date: 3 Aug 90 19:04:46 GMT
References: <7967@jarthur.Claremont.EDU> <2600@dataio.Data-IO.COM> <161@srchtec.UUCP>
Distribution: na
Organization: Data I/O Corporation; Redmond, WA
Lines: 41

In article <161@srchtec.UUCP> johnb@srchtec.UUCP (John Baldwin) writes:
<In article <2600@dataio.Data-IO.COM> bright@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.