About checkmycode.org

checkmycode.org is a service that allows you to compare your code with the "wisdom of the crowds" — over 200 million lines of C code from the Gentoo Linux distribution. All anomalies found in your code will be reported to you along with an explanation of why parts of your code are considered anomalous — and therefore possibly buggy. For details about the technique, please consult our publications.

How to use

To get your code checked, paste it into the textfield that can be found on the main page. checkmycode.org will then compare your code with over 200 million lines of C code from the Gentoo Linux distribution and report any anomalies to you. As an example of how anomalies look like and how to interpret checkmycode.org's output, consider the following two examples:

Example 1

Submit the following code snippet to checkmycode.org: 

	void foo (void)
	{
	        struct sockaddr_in SAddr;
	        int sok;
	        socklen_t len;

	        sok = socket (AF_INET, SOCK_STREAM, 0);

	        memset (&SAddr, 0, sizeof (struct sockaddr_in));
	        SAddr.sin_family = AF_INET;
	        SAddr.sin_addr.s_addr = ip;
	        SAddr.sin_port = htons (port);
	        bind (sok, (struct sockaddr *) &SAddr, sizeof (SAddr));

	        len = 1;
	        setsockopt (sok, SOL_SOCKET, SO_REUSEADDR, (char *) &len, sizeof (len));

	        listen (sok, 1);
	}

After analyzing this code snippet, checkmycode.org will report exactly one anomaly with a summary "There are problems with calls to setsockopt, bind." This immediately points you to those places in the code that are anomalous and need your attention — in this case, the calls to setsockopt and bind.

checkmycode.org also gives you a detailed graphical representation of the anomaly that allows you to understand what the problem is:

example 1

This is what different colors mean:

example 1, phase 1

This is the meaning of the blue elements:

example 1, phase 2

This is the meaning of the red element:

example 1, phase 3

Comparing the comment to the red arrow in the figure above with the code we submitted confirms that the code misses the link represented by the arrow. Moreover, the reverse flow of values happens in the code. As it is, this anomaly is in fact a defect that makes the call to setsockopt a no-op, because the socket option that is being set cannot influence the behavior of bind anymore.

In addition to graphical representation checkmycode.org gives you a textual representation of the anomaly. It contains the same information as the graphical representation, so you can choose to use the one you find most convenient. The anomaly found by checkmycode.org for the snippet above has the following textual representation: 

	DATA FLOW IN YOUR CODE:
	1st arg of bind() -> 1st arg of listen()
	1st arg of setsockopt() -> 1st arg of listen()
	MISSING DATA FLOW:
	1st arg of setsockopt() -> 1st arg of bind()

Each line in the textual output corresponds to an arrow in the graphical representation and has the same meaning. Present temporal properties correspond to blue arrows, while missing temporal properties correspond to red arrows.

To help you understand why your code is considered anomalous and decide if it indeed needs fixing or not, checkmycode.org gives you a possibility to look at three examples from the Gentoo Linux distribution. These examples use the same function calls as your code, but in a way that is considered correct. For instance, the examples for the anomaly above all call setsockopt, bind, and listen, and in each of them the first argument to setsockopt is later passed as the first argument to bind.

Example 2

Submit the following code snippet to checkmycode.org: 

	void bar (void)
	{
	    DIR *dirp;
	    struct dirent *dirinfo;

	    dirp = opendir(".");
	    while ((dirinfo = readdir(dirp)) != NULL) {
	        process(dirinfo);
	    }
	    rewinddir(dirp);
	}

After analyzing this code snippet, checkmycode.org will report exactly one anomaly with a summary "A call to closedir is missing. There is a problem with a call to opendir." The graphical representation of the anomaly looks as follows:

example 2

The textual representation of the anomaly looks as follows: 

	DATA FLOW IN YOUR CODE:
	1st arg of readdir() -> 1st arg of readdir()
	return value of opendir() -> 1st arg of readdir()
	MISSING DATA FLOW:
	return value of opendir() -> 1st arg of closedir()

This is the meaning of the blue elements:

example 2, phase 2

This is the meaning of the red elements:

example 2, phase 3

Comparing the comment to the red elements in the figure above with the code we submitted confirms that the code misses the call to closedir, and therefore also misses the link between opendir and closedir. As it is, this anomaly is in fact a defect that results in a resource leak, because the DIR object is never properly closed.

Notice that checkmycode.org does not tell you if the call to readdir should come before the call to closedir or not (there is no arrow at all between the events "1st argument of readdir" and "1st argument of closedir"). However, let us change the snippet above to the following one (in effect fixing the reported anomaly, but introducing a new problem): 

	void bar (void)
	{
	    DIR *dirp;
	    struct dirent *dirinfo;

	    dirp = opendir(".");
	    closedir(dirp);
	    while ((dirinfo = readdir(dirp)) != NULL) {
	        process(dirinfo);
	    }
	    rewinddir(dirp);
	}

checkmycode.org then reports the following anomaly: "There are problems with calls to closedir, readdir." The graphical representation of the anomaly looks as follows:

example 3

This is the meaning of the blue elements:

example 3, phase 2

This is the meaning of the red elements:

example 3, phase 3

There is a red arrow in the figure above between "1st argument of readdir" and "1st argument of closedir". It points to the problem we have just introduced: we have put the call to closedir in the wrong place: it should come after the call to readdir. Let us now fix the problem and move the call to closedir to the correct place and see what happens. Submit the following code snippet to checkmycode.org: 

	void bar (void)
	{
	    DIR *dirp;
	    struct dirent *dirinfo;

	    dirp = opendir(".");
	    while ((dirinfo = readdir(dirp)) != NULL) {
	        process(dirinfo);
	    }
	    rewinddir(dirp);
	    closedir(dirp);
	}

checkmycode.org checks the code and does not report any anomaly and, indeed, the code is correct.

As we have just seen, checkmycode.org can not only find problems in your code, but it can also be used to verify your fixes. However, keep in mind that in the end, the programmer has to decide if the anomaly is really a problem or just a false alarm. Have fun!

 
please enable javascript