Re: problems/risks due to programming language

[hammondr@sunroof.crd.ge.com (Richard A Hammond)]

In article <8126@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
 .... [ in discussion of the AT&T bug]
>   The problem cannot simply be defined out of existence by saying,
>   in essence, that good programmers don't make mistakes.  All human
>   programmers make mistakes, and a well-designed language will help
>   to minimize this particular tendency.  In this case, C does not. 
       ^^^^^^^^

Uh Oh! I agree with Bill.  The problem here is that the original request was
for cases where a different language would have PREVENTED the error, that is,
reduced the probability to 0.0 .

Another example was a FORTRAN program fragment:

	DO 10 I = 1.100
which the compiler treated as:	DO10I = 1.100
while the programmer wanted:	DO 10 I = 1, 100

Using another language that was sensitive to spaces between characters would
have PREVENTED the problem.

Now the AT&T problem in C & Ada was:

	C Version			Ada Version
  do {				OUTER:	loop 
	...				    ...
	switch ...			    case ... is
	    {
	    case ... :				when ... =>
		if ( ...) {			    if ... then
		    ...					...
		    break;				exit; -- exits OUTER!!
		}				    end if;
		...				    ...
		break;				when ... =>
	    } /* end case */		    end case;
	...				    ...
  } while ( ...) ;			    exit OUTER when ... ;
					end loop OUTER;

I agree with Bill that Ada would minimize the chance of getting an "exit"
in there, since it doesn't need one at the end of each case.
However, it wouldn't PREVENT it, since the Ada and C fragments are both
not only legal, but sensible.

So I claim that the AT&T problem does not fall in the same class as the
FORTRAN do loop problem, switching to Ada would have made the mistake less
likely but not removed the possibility of it entirely.  Particularly if the
programmer really had the misconception that exit/break left if statements.

Rich Hammond