Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!ericom!eua.ericsson.se!erix.ericsson.se!rv
From: rv@erix.ericsson.se (Robert Virding)
Newsgroups: comp.lang.c
Subject: Re: Seven Original Sins of K&R (Long)
Message-ID: <1990Sep26.124303.10527@eua.ericsson.se>
Date: 26 Sep 90 12:43:03 GMT
References: <12780@sdcc6.ucsd.edu>
Sender: news@eua.ericsson.se
Reply-To: rv@erix.ericsson.se (Robert Virding)
Organization: Ellemtel Telecom Systems Labs, Stockholm, Sweden
Lines: 85

In article <12780@sdcc6.ucsd.edu>, mautner@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? :-)