To get on this list, a bug has to be able to cause at least half a day of futile head scratching, and has to be aggravated by the poor design of the "C" language. In the interests of equal time, and to see how the world has progressed in the 20-odd years since "C" escaped from its spawning ground, see my Top 10 Ways to be Screwed by the Java programming language, and for more general ways to waste a lot of time due to bad software, try my Adventures in Hell page.
A better language would allow fallible programmers to be more productive. Infallible programmers, of the type unix' and "C" designers anticipated, need read no further. In fairness, I have to admit that the writers of compilers have improved on the situation in recent years, by detecting and warning about potentially bad code in many cases. Non-terminated comment, "accidentally" terminated by some subsequent comment, with the code in between swallowed.
a=b; /* this is a bug
c=d; /* c=d will never happen */
Accidental assignment/Accidental Booleans
if(a=b) c; /* a always equals b, but c will be executed if b!=0 */
Depending on your viewpoint, the bug in the language is that the assignment operator is too easy to confuse with the equality operator; or maybe the bug is that C doesn't much care what constitutes a boolean expression: (a=b) is not a boolean expression! (but C doesn't care).
A better language would allow fallible programmers to be more productive. Infallible programmers, of the type unix' and "C" designers anticipated, need read no further. In fairness, I have to admit that the writers of compilers have improved on the situation in recent years, by detecting and warning about potentially bad code in many cases. Non-terminated comment, "accidentally" terminated by some subsequent comment, with the code in between swallowed.
a=b; /* this is a bug
c=d; /* c=d will never happen */
Accidental assignment/Accidental Booleans
if(a=b) c; /* a always equals b, but c will be executed if b!=0 */
Depending on your viewpoint, the bug in the language is that the assignment operator is too easy to confuse with the equality operator; or maybe the bug is that C doesn't much care what constitutes a boolean expression: (a=b) is not a boolean expression! (but C doesn't care).
Closely related to this lack of rigor in booleans, consider this construction:
if( 0 < a < 5) c; /* this "boolean" is always true! */
Always true because (0<a) generates either 0 or 1 depending on if (0<a), then compares the result to 5, which is always true, of course. C doesn't really have boolean expressions, it only pretends to. Or consider this: if( a =! b) c; /* this is compiled as (a = !b), an assignment, rather than (a != b) or (a == !b) */Unhygienic macros
if( 0 < a < 5) c; /* this "boolean" is always true! */
Always true because (0<a) generates either 0 or 1 depending on if (0<a), then compares the result to 5, which is always true, of course. C doesn't really have boolean expressions, it only pretends to. Or consider this: if( a =! b) c; /* this is compiled as (a = !b), an assignment, rather than (a != b) or (a == !b) */Unhygienic macros
#define assign(a,b) a=(char)b
assign(x,y>>8)
becomes
x=(char)y>>8 /* probably not what you want */ Mismatched header filesRead more: The Top 10 Ways to get screwed by the "C" programming language
assign(x,y>>8)
becomes
x=(char)y>>8 /* probably not what you want */ Mismatched header filesRead more: The Top 10 Ways to get screwed by the "C" programming language
Posts
0 comments:
Post a Comment