problems/risks due to programming language, stories requested

[jbaker]

In article <8218 at hubcap.clemson.edu> Bill Wolf writes:
>From dave at micropen (David F. Carlson):
>>> For what it's worth, my personal opinion is that C lends itself to 
>>> precisely the kinds of errors noted above--when does break work and when 
>>> doesn't it, and why in God's name do you need it in switch statements in 
>>> the first place, etc.
>> 
>> A multi-case switch is very handy in many situations to reduce identical
>> treatments for similar cases.  

But the real usefulness of requiring break in a switch statement is for
SIMILAR treatments of similar cases, for example you may require a
few assignments in one case before a more complicated computation which
must be performed for several of the cases.

This could be done in other languages using conditionals or multiple case
statements, but it's not quite as nice.

Bill Wolf writes:
>   So is a multi-alternative case, as provided by Ada:
>
>      case Foo is
>         when 1 | 3 | 5 =>
>            statement1;
>         when 2 | 4 | 6 =>
>            statement2;
>         when others =>
>            statement3;
>      end case;
>
>   The difference is that Ada takes care of exiting the case statement
>   for you, whereas C requires (unsafely) that you use a break to avoid 
>   being sucked into the code associated with subsequent cases.  
>
But this is just one example of the design philosophy of C: flexibility;
if the machine will let you do it (or naturally WANTS to do it), let the
programmer do it the same way.  Other examples of such flexibilty are the
lack of type-checking, as well as allowing assignments just about anywhere.

Some languages, such as Pascal, have more limitations (or less extentions)
in their constructs.  This usually is perfectly adequate, but for someone
who writes code while thinking about how the machine will execute that 
code, as I do, flexibility can be useful; a small amount of speed-up, and more
compact code can be the result. 

However, this capability has a trade-off; flexibility for follow-ability.
Humans do not think like computers.  We can not precisely process syntax.
When code becomes too involved, it can become very difficult to follow for
even the author.  What could be a straight-foward program may now be a twisted
mess.  It becomes easy to overlook bugs that would be obvious in other
languages.  This is why C programmers rely heavily on a debugger.
What one calls "safety" in a language, then, is just how well humans can
follow a construct, without regard for its usefulness.  C is not "safe,"
but while being quite simple and relatively low-level, it contains many
flexible constucts.

Sometimes, though, flexibility is present in other languages in a more
"safe" fashion.  For example, type conversion is available in Modula-2
IF it is explicitly done in the code.  In order to use a pointer as a
integer, for example, one might use: INTEGER(ch^).  This flags the compiler
that "we meant to do that" and warns humans that something tricky is going on.

But C can be delightful to use, if you are very careful to write clear code.


John Baker
jbaker at gmuvax.gmu.edu

Now about deciphering all those }++|#{ symbols....