problems/risks due to programming language, stories requ

[Andrew P. Mullhaupt]

In article <1306 at mindlink.UUCP>, a563 at mindlink.UUCP (Dave Kirsch) writes:
> 
> C flaws?  Do this in Pascal:
> 
> switch (i) {
>   case 2 :  /* Add 2 to j */
>     j++;
>   case 1 :  /* Add 1 to j */
>     j++;
>   case 0 :  /* Print j out */
>     printf("%d\n", j);
>     break;
>   default :
>     printf("Illegal value in switch.\n");
>     abort();
> }
> 
> In pascal you have to:
   [... stuff which it turns out is needlessly complex deleted...]

My approach to your fragment is:


   if i in [0..2] then
       begin
           j := j + i; writeln(j);	(* optional semicolon religion *)
       end
   else
       writeln('Illegal value in switch.');
           (* dubious message for strict compatibility with C version *)

Seems to me you've gone a little over the top with C side effect
operators. They should get about 1/3 the use they actually do. Now
I would still prefer the C version to use 'j = j + i' as opposed to
'j += i' but a lot of C programmers who like to think about operator
precedence will prefer the latter. 

Now I think I know what you're driving at, but before getting to that,
let me point out that your code only looked right to you because you
feel comfortable with the sometimes tangled C syntax. I would guess
that your example indicates that you're too comfortable with it. This
is the kind of thing that can happen to you if you let all the people
who tell you 'after you get used to thinking in C you'll see why it's
better our way...' subvert your standards of thought. 

There is a little fragment called "Duff's device" (which can be found
in one of Bjarne Sjostroup's (spelling?) books). It is an example where
fall-through is about as elegant as fall-through gets, and it involves
writing a loop and a case statement together. It's clever, but it breaks
some C compilers. It too, is a good example of the fallacious benefit
of fall-through. It is supposed to gain some run-time advantage, but
unless your compiler is really old, this benefit is equally available
from much simpler code. Now it's a museum piece.

Disclaimer: I am not a Pascal fanatic. It has a couple rough spots 
(the nontrivial use of 'with' clauses is an accident waiting to 
happen, for one example), but I think C as practiced requires a higher
tolerance for risky code than a lot of other languages. A lot of
people who only program in C don't mind this. (It's much like the APL
community in that respect...) But guys like me who have to work in
two dialects of APL, FORTRAN, and C (I have to glue one of the APL
dialects to FORTRAN through C...) and have worked extensively in the
past in other mixtures, are not going to buy this line. It all boils
down to whether or not you believe in David Gries' principle that you
should program INTO a programming language, not IN one. 

Later,
Andrew Mullhaupt