Seven Original Sins of K&R (Long)
Robert Virding
rv at erix.ericsson.se
Wed Sep 26 22:43:03 AEST 1990
In article <12780 at sdcc6.ucsd.edu>, mautner at odin.ucsd.edu (Craig Mautner) writes:
> Seven Original Sins of K&R
> by Philip J. Erdelsky
>
> I
> {Weak typing, reaaly no bools and char neither signed or unsigned}
> The "char" type was not specified as either
>signed or unsigned. This sin has probably wasted more
>CPU time than any other, as savvy programmers learn to
>put a defensive "&0xFF" after every "char" expression
>that needs to be unsigned.
This is no REAL problem, if you are going to do operations which
should be unsigned, just declare the variables as 'unsigned char'. A
(really) savvy programmer would *NEVER* put a &0xff after every char
expression. A novice would.
> II
> Some compilers don't even object when
>you assign an integer constant to a pointer without a
>typecast, especially when the constant happens to be
>zero. Don't blame the compiler. The poor thing can't
>tell the difference between a zero integer constant and
>"NULL".
According to the language definition assigning a zero to a pointer is
perfectly legal, the compiler shouldn't complain. All C compilers I
have seen will complain for any other integer. For the 50 million'th
time in this group, there is no difference between zero and NULL.
> III
> {static}
Granted.
> IV
> {break}
What's the problem? "break" means break out of the surrounding
while/for/case. The REAL sin is that "break" ignores a surrounding if.
This really can cause problems.
>The solution, not likely to be adopted even in C+++,
>would be to have the compiler put an implicit "break"
>at the end of every "case" clause, and reserve the
>"break" keyword for breaking out of loops, the way God
>intended.
I hope it is NEVER adopted! Being able to "fall through" is extremely
pratical and saves much code copying or "goto"s. Adding the "break" is
really no problem.
> V
> {defining function arguments}
>Most programmers have written something like
>"strcmp(s,t)", forgetting the declaration "char
>*s,*t;". What you wind up with in most cases is, not a
>function that fails, but something worse--a function
>that works as long as pointers and integers are the
>same size, and then fails when you try to port it.
Actually all compilers will complain when you try to USE "s" and "t"
as pointers
> VI
> {struct member name conflicts}
True, but extremely practical. Saved typing, no need to define a union
of possible structures and adding union element names to every
reference :-).
> VII
>{eight character name limit}
Agreed, but unfortunately C had/has to exist on systems which
themselves limit the name length (in linkers and such). We could I
suppose always say "don't run C on such systems".
> Epilogue
>
>None of these sins is inconsistent with the philosophy
>of C.
If the sins are consistent with the philosophy of C would there
correction then be inconsistent? :-)
More information about the Comp.lang.c
mailing list