Criticism of the C programming language: Difference between revisions

Content deleted Content added
Tools for mitigating issues with C: previous edit followed summary paragraph; removed unsubstantiated claims, and rduced GCC details to one entence in a better ___location
Line 144:
There are many C programmers who have learned to cope with C's quirks. However, some programmers may wish to use tools that have been created to help them overcome such problems.
 
Automated [[source code]] checking and auditing are beneficial in any language, and for C many such tools exist, such as [[lint programming tool|Lint]]. A common practice is to use Lint to detect questionable code when a program is first written. Once a program passes Lint, it is then compiled using the C compiler. Many compilers can optionally warn about syntactically valid contructs that are likely to actually be errors.
 
There are also compilers, libraries and [[operating system]] level mechanisms for performing array bounds checking, [[buffer overflow]] detection, and [[garbage collection (computer science)|automatic garbage collection]], that are not a standard part of C.
Line 153:
 
It should be recognized that these tools are not a panacea. Because of C's flexibility, some types of errors involving misuse of variadic functions, out-of-bounds array indexing, and incorrect [[memory management]] cannot be detected on some architectures without incurring a significant performance penalty. However, some common cases can be recognized and accounted for.
 
The general solution to problems which are caused by the syntactic freedom of C is to use compiler flags (options) which pedantically give warnings on deviant constructions. A paranoid example for the
[http://en.wikipedia.org/wiki/GNU_Compiler_Collection GNU gcc] compiler:
 
<pre>
gcc -c -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \
-Wcast-qual -Wchar-subscripts -Winline \
-Wmissing-prototypes -Wnested-externs -Wpointer-arith \
-Wredundant-decls -Wshadow -Wstrict-prototypes -Wwrite-strings myprogram.c
</pre>
 
It has been observed that C code by programmers who were trained in a strict language (such as Pascal) using structured programming, is easy to read and be maintained. The most difficult C code is from the early period where many programmers wanted to squeeze too much into a cryptic one liner. Today we know that software maintenance is much too costly to allow for such eccentricity. As better compilers became available and standard habits of coding as well as explicitly [http://www.doc.ic.ac.uk/lab/secondyear/cstyle/cstyle.html standardized C-coding styles] have been achieved, many of the disadvantages of C have been alleviated, in practice.
 
== See also ==