Programming essence-writing high-quality C language code (1): Hypothetical Compilation Program

Compilation programs can only query and find out program syntax errors. For errors such as "array out-of-bounds access" and "unreferencing null Pointers", compilation programs are helpless. At the same time, we know that the black box testing method used by testers can only fill in data in the program and see what it pops up. This determines that it may take some luck to detect program errors.

If the compilation program detects errors such as "array out-of-bounds access", "one error", and "Null Pointer", it is much easier to write error-free code.

Therefore, we need a shift of thinking: we should not rely solely on the black box testing method. We should also try to imitate the hypothetical Compilation Program mentioned above to eliminate the influence of luck on program testing, automatically seize every opportunity for errors.

A good compiled program should be able to think of the Legal C-habit of repeated errors as errors in the program. What does this sentence mean? Some C usage is legal in terms of syntax, but it often brings unexpected errors to the program. So a good compilation program should provide support: Let's take these usage as an error.

For example:

/* Memcpy copy a memory block */void * memcpy (void * pvTo, void * pvFrom, size_t size) {byte * pbTo = (byte *) pvTo; byte * pbFrom = (byte *) pvFrom; while (size --> 0); * pbTo ++ = * pbFrom ++; return pvTo ;}

Compiling a program will make the program compile happily. However, after the program runs, it may take a lot of time to debug this very hidden error: a semicolon is added after the while condition judgment statement, this causes the loop body to be empty. This is clearly not the programmer's intention, but the compiler cannot detect this error, because the null statement is legal from the syntax perspective.

Although it is legal to use a C-language hollow statement, it is seldom used in this way. When a null statement appears, it is often caused by the carelessness of the programmer, such empty statements can also cause hidden deep errors. So when an empty statement appears, if the compiler considers it as an error and automatically gives us a warning, it makes it very easy for us to find out the error.

Of course, if we do need to use an empty statement, we can use it. However, it is best to use NULL to make it visible. NULL is only a constant, so the compiler does not generate any code for the NULL statement. In this way, the Compilation Program only accepts the displayed NULL statement, and marks the implicit NULL Statement (that is, there is only one semicolon) as an error. This allows us to use empty statements explicitly and indicate the empty statements that are often caused by errors implicitly.

Another common problem is unintentional assignment. For example

if(ch=‘\t')    ExpandTab()；

We want to determine whether ch is equal to '\ t', but it causes' \ t' to be assigned to ch, which leads to a very different program behavior than we expected. However, the compiler does not complain because it is a valid C statement. Therefore, some compilation programs allow users to disable simple assignment in & | and if, for, and while expressions. This will help you identify such errors. The basic basis for this is that the user is very likely to "=" into "=" in the above five situations ".

But sometimes for the simplicity of the code, we may write the following code:

while(*pchTo++=*pchFrom++)    NULL;

So to avoid warning information, we can write

while((*pchTp++=*pchFrom)!='\0')    NULL;

Although this may seem troublesome, modern commercial compilers will not generate additional code for this redundant code and will optimize it. At the same time, it can reduce risks and improve security.

Null statements, incorrect assignments, and prototype checks are only a small part of the selection items provided by many C compilation programs. In fact, there are more options. The main point here is: the Compilation Program warning facility that the user can select can send a warning message to the user for possible errors. Although sometimes we may need additional work for these warning facilities, we should regard these warning facilities as a risk-free high-Reimbursement Program investment.

Use all the optional warning facilities of the Compilation Program.

Another way to check for errors is more detailed. A more thorough approach is to use lint. The lint tool was initially used to scan the C source file and warn against unportable parts of the source program. Now the lint utility has become more rigorous, lint can detect that although portable and fully compliant with the syntax, it is likely to be a bad feature.

Use lint to check for errors missed by the Compilation Program.

Sometimes, it seems that you can skip some steps designed to avoid program errors, such as unit tests, but it is time to take a shortcut.

If unit tests exist, unit tests are conducted.

Conclusion: When you write a program, you must keep in mind the concept of hypothetical compiling program, so that you can spend little effort to seize every opportunity to seize errors. Consider the Errors generated by compiling programs, the lint errors, and the causes of unit test failures. The best way to eliminate program errors is to identify errors as early as possible, and to seek the least-effort automatic error method.

Finally, I end this article with an introduction from the author in this chapter:

The difference between investors and gamblers is that investors take advantage of every opportunity, no matter how small it is, to strive for benefits; while gamblers rely only on luck.