problems/risks due to programming language, stories requested

problems/risks due to programming language, stories requested

[Gerald Baumgartner]

For a research project I am collecting information about the risk of
choosing the wrong programming language. In particular I am looking
for problems that could have been avoided if another (a better)
programming language would have been used.

I know of these three such stories:

     1.	There is the famous story that a Mariner probe got lost
	because of the Fortran statement `DO 3 I = 1.3' (1.3 instead
	of 1,3) (see Peter Neumann: A Few Old War Stories Reappear.
	ACM SIGSOFT 11(5), Oct. 1986, pp. 16-18). It is a nice story
	but, as far as I know, NASA used Jovial at that time and not
	Fortran.

     2. One of the security holes the Internet Worm took advantage of
	was in fingerd (the finger deamon). The deamon uses the gets
	routine for input. This routine, written in C, reads input
	without checking for bounds on the buffer involved. By
	overrunning the buffer, the worm rewrote the stack frame (see
	Eugene H. Spafford: Crisis and Aftermath. Communications of
	the ACM 32(6), June 1989).

	There would be no security hole in the finger daemon if a
	programming language would have been used for the I/O
	routines, where the compiler takes care of boundary checks for
	arrays. Pascal doesn't work since variable length strings are
	needed, but Ada would be fine. A language a la ML, where these
	checks are done at compile time, would be even better.

     3. The AT&T breakdown a month ago was caused by a break statement
	in C. See the following mail (multiple forwarding headers deleted):

Subject: AT&T software problem
Subject: Cautionary note on C programming...AT&T learns from experience
>From: kent@wsl.dec.com
Subj:	I've always thought C looked like line noise.
Subj:	the bug
Subj:	AT&T's bug, for you C users out there...
Subj:	I C what they mean!
Subj:	"c" considered dangerous to telephones
Subj:	Be careful from where you break! (else no long distance calls will make it thru...)
Subj:	C switch breaks AT&T switches!
Subj:	your "c users" list might appreciate this....


I received the following on AT&T's famous bug (and have deleted multiple 
forwarding headers):

| | Subject: AT&T Bug
| | Date: Fri Jan 19 12:18:33 1990
| | 
| | This is the bug that cause the AT&T breakdown
| | the other day (no, it wasn't an MCI virus):
| | 
| | In the switching software (written in C), there was a long
| | "do . . . while" construct, which contained
| |    a "switch" statement, which contained 
| |       an "if" clause, which contained a
| |          "break," which was intended for
| |       the "if" clause, but instead broke from
| |    the "switch" statement.
| | 

	Again it looks like this bug wouldn't have occurred in another
	programming language.

You C what I mean? Do you know other stories like these, if possible
with references? I don't want to praise Ada or pick at C and Fortran;
I am looking for any story where a proveably inappropriate/insecure
programming language has been used.


Gerald Baumgartner   gb@cs.purdue.edu   ...!{decwrl,gatech,ucbvax}!purdue!gb

Re: problems/risks due to programming language, stories requested

[Richard A Hammond]

In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes:

>For a research project I am collecting information about the risk of
>choosing the wrong programming language. In particular I am looking
>for problems that could have been avoided if another (a better)
>programming language would have been used.

>I know of these three such stories:
	...
>     3. The AT&T breakdown a month ago was caused by a break statement
>	in C. See the following mail (multiple forwarding headers deleted):

>| | This is the bug that cause the AT&T breakdown
>| | the other day (no, it wasn't an MCI virus):
>| | 
>| | In the switching software (written in C), there was a long
>| | "do . . . while" construct, which contained
>| |    a "switch" statement, which contained 
>| |       an "if" clause, which contained a
>| |          "break," which was intended for
>| |       the "if" clause, but instead broke from
>| |    the "switch" statement.
>| | 
>
>	Again it looks like this bug wouldn't have occurred in another
>	programming language.

What other programming language?  Only one without any GOTO or restricted
GOTO (e.g. exit, break, ...).  This leaves out Ada!!!!!!

Similar bug in Ada: 	(Cut down for posting, but gives the flavor)

procedure test is
        MAX : constant := 10; 
        type t is array(positive range 1 .. MAX) of boolean; 
        NEW_ITEMS : t; 
 
    begin 
        for N in 1 .. MAX loop 
	    case ...
	    when ... =>
                if NEW_ITEMS(N) = FALSE then 
			-- some other useful work gets done here
                        exit; 			-- exits loop, not if!
                end if; 
	    when ... =>
	    end case;
        end loop; 
    end test;

So, in the AT&T case using Ada we would have exited both the switch and the
loop rather than just the switch.  Hardly an improvement!

More generally, I find it distressing that the advocates of Ada are
failing to distinguish between language independent features and language
dependent features in assigning credit for software improvements.

In my limited experience the cases where Ada is introduced into a
programming environment also introduce lots of other good software
engineering practices.  For example, lots of people I know who
program in C don't use LINT.   I view it as a deficiency of management
and not of the language that they don't use available tools.

I bring this up because Ada isn't the last language ever to be designed
and we should be willing to learn what could be used in future languages.

Rich Hammond

Re: problems/risks due to programming language

[William Thomas Wolfe, 2847]

From hammondr@sunroof.crd.ge.com (Richard A Hammond):
>>     3. The AT&T breakdown a month ago was caused by a break statement
>>	in C. See the following mail (multiple forwarding headers deleted):
> 
>>| | In the switching software (written in C), there was a long
>>| | "do . . . while" construct, which contained
>>| |    a "switch" statement, which contained 
>>| |       an "if" clause, which contained a
>>| |          "break," which was intended for
>>| |       the "if" clause, but instead broke from
>>| |    the "switch" statement.
>>| | 
>>
>>	Again it looks like this bug wouldn't have occurred in another
>>	programming language.
% 
% What other programming language?  Only one without any GOTO or restricted
% GOTO (e.g. exit, break, ...).  This leaves out Ada!!!!!!
% 
%  [...]  for N in 1 .. MAX loop 
% 	    case ...
% 	    when ... =>
%                 if NEW_ITEMS(N) = FALSE then 
% 			-- some other useful work gets done here
%                         exit; 			-- exits loop, not if!
%                 end if; 
% 	    when ... =>
%   [...] 
% So, in the AT&T case using Ada we would have exited both the switch and the
% loop rather than just the switch.  Hardly an improvement!

   This is not a valid analogy.  In C, the case statement *requires* the
   use of a restricted GOTO in order to accomplish "normal" processing;
   at the end of the section of code processing a given case, one must
   use a restricted GOTO in order to prevent C from sending the flow of
   control straight into the section of code which was intended to process
   the NEXT case.  In other words, C requires the programmer to use a
   dangerous construct on a routine basis.

   With the if construct in C, the default is to exit the if construct 
   automatically, as opposed to continuing on to execute the section of
   code associated with the else part.  Thus, we have an inconsistency
   in C's design: with one flow-of-control construct (the switch), it is
   necessary to use a dangerous GOTO to achieve normal processing, whereas
   with a similar flow-of-control construct (the if-else), the default is
   reversed.  Given such a language design, it should not surprise anyone
   that programmers become confused, particularly when the constructs are
   being used together. 

   Ada, on the other hand, is consistent: in both the if and case statements,
   the default is to exit the construct once the code associated with the
   specified situation has been executed.  Ada also provides the exit
   statement, a restricted GOTO which permits a loop to be exited early,
   but this construct is not used (as is C's break) on a routine basis.  

> In my limited experience the cases where Ada is introduced into a
> programming environment also introduce lots of other good software
> engineering practices.  For example, lots of people I know who
> program in C don't use LINT.   I view it as a deficiency of management
> and not of the language that they don't use available tools.

   This is certainly true; Brooks and others have noted that the good
   software engineering practices which are routinely introduced in
   conjunction with the Ada language are responsible for more of the 
   resulting improvements than the fact that the Ada language was
   introduced.  However, we cannot disregard that fact that Ada was
   specifically designed to provide maximal support for the software 
   engineering process.  C, on the other hand, was designed to provide
   maximal support for the compilation process.  Since compilers and 
   the CPU power required to operate them come far more cheaply than 
   programmers, and especially in view of the fact that better error
   prevention is worth much more than faster compilation, it would seem
   that the tradeoff made by Ada is certainly the one to be preferred.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: problems/risks due to programming language

[Richard A Hammond]

In article <8103@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
...
>   This is not a valid analogy.  In C, the case statement *requires* the
>   use of a restricted GOTO in order to accomplish "normal" processing;
    ...
>   With the if construct in C, the default is to exit the if construct 
>   automatically, as opposed to continuing on to execute the section of
>   code associated with the else part.  Thus, we have an inconsistency
>   in C's design: with one flow-of-control construct (the switch), it is
>   necessary to use a dangerous GOTO to achieve normal processing, whereas
>   with a similar flow-of-control construct (the if-else), the default is
>   reversed.  Given such a language design, it should not surprise anyone
>   that programmers become confused, particularly when the constructs are
>   being used together. 

Bull!!! I've seen lots of errors in C code, and this is the first time I've
seen or heard of such an error.  If it really was all that confusing, I'd
expect to have seen it much more frequently.  In fact, the structures are quite
different, since a case in a switch has a sequence of statements without any
additional brackets, whereas an if statement controls only a single statement,
so it is usually followed by "{" and "}" to bracket multiple statements.
I expect it was an editing error that pulled the "break" inside the
if, rather than leaving it at the end of the case.

If that is true, then the same error could be made in Ada, it certainly is
not PREVENTED in Ada.  As the anti-nuclear protesters will gladly explain,
0 risk and a reduced risk are not the same!!!!

>   ...  C, on the other hand, was designed to provide
>   maximal support for the compilation process.

Where did you get this idea?  I believe a better statement is found in
AT&T Bell Laboratories Technical Journal, Vol 63, No 8, Part 2, pg 1686,
Oct. 1984

"A major trend in the development of C is toward stricter type checking,
along the lines of languages like Pascal.  However, in accordance with
what has been called the "spirit" of C (meaning a model of computation
that is close to that of the underlying hardware), many areas of the
language specification deliberately remain permissive."

This does not imply that it was meant to support the compilation process,
but rather, that without huge runtime libraries I could run something
through a C compiler and execute it on a bare machine.

Rich Hammond

Re: problems/risks due to programming language

[John F Nixon]

billwolf (William Thomas Wolfe, 2847 ) writes:
>From hammondr@sunroof.crd.ge.com (Richard A Hammond):
>> So, in the AT&T case using Ada we would have exited both the switch and the
>> loop rather than just the switch.  Hardly an improvement!
>   This is not a valid analogy.  In C, the case statement *requires* the
>   use of a restricted GOTO in order to accomplish "normal" processing;

But we aren't talking about using the "break" in this sense, we are talking
about using the "break" to exit an "if", something which isn't C.

> In other words, C requires use [of] a dangerous construct on a routine basis.

Just as Ada requires the use of "exit" to leave the "loop" construct;
unless you use Ada'a "goto"...

>   With the if construct in C, the default is to exit the if construct 
>   automatically, as opposed to continuing on to execute the section of
>   code associated with the else part.  Thus, we have an inconsistency
>   in C's design: with one flow-of-control construct... use(s) dangerous
>   GOTO [normally] whereas a similar flow-of-control construct... default is
>   reversed.  Given such a language design, it should not surprise anyone
>   that programmers become confused, particularly when the constructs are
>   being used together. 

This argument applies equally to Ada's "loop" construct versus Ada's
"if" construct.

>   Ada, on the other hand, is consistent: in both the if and case statements,

Ignoring the example presented (Ada's loop and exit).

>   the default is to exit the construct once the code associated with the
>   specified situation has been executed.  Ada also provides the exit
>   statement, a restricted GOTO which permits a loop to be exited early,
>   but this construct is not used (as is C's break) on a routine basis.  

Unless one uses the "loop" statement on a routine basis.  Bill may not, but
what if I do?  And if the reversed sense is such a bad example of
program language design, then Ada is an example of bad program
language design.  

I'm not trying to tag Ada, or praise C, but simply to make the point that
this case is *not* an example of error a language such as C or Ada 
detects.  Both programs are legal, both will compile, both are wrong.
Neither C nor Ada are free of flaws.  However, C has not made claims
such as the one which follows:

>   However, we cannot disregard that fact that Ada was
>   specifically designed to provide maximal support for the software 
>   engineering process.

I agree.

However, Ada doesn't pass the test in this case.  It is possible (nay,
inevitable) that someone will misuse the Ada exit statement.  And it is
likely that someone will correctly use the exit statment
in exactly this fashion.  Too bad you can't tell till runtime.



----
jnixon@atl.ge.com                    ...steinmetz!atl.decnet!jnxion

Re: problems/risks due to programming language

[Scott MacHaffie]

In article <8103@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>   the NEXT case.  In other words, C requires the programmer to use a
>   dangerous construct on a routine basis.

(the dangerous construct is the "break" statement)
But if "break" were renamed "end case" then there wouldn't be any problem?

>   code associated with the else part.  Thus, we have an inconsistency
>   in C's design: with one flow-of-control construct (the switch), it is
>   necessary to use a dangerous GOTO to achieve normal processing, whereas

No, it is necessary to use a statement to indicate that the current case
statement is finished...like an "end case" or the next "when => " in ADA.

>   with a similar flow-of-control construct (the if-else), the default is
>   reversed.  Given such a language design, it should not surprise anyone
>   that programmers become confused, particularly when the constructs are
>   being used together. 

Some programmers become confused -- good programmers, and software engineers,
don't.

>   specified situation has been executed.  Ada also provides the exit
>   statement, a restricted GOTO which permits a loop to be exited early,
>   but this construct is not used (as is C's break) on a routine basis.  

In all the ADA I have seen, the preferred looping construct is a "loop"
with exit statements sprinkled throughout it. On the other hand, C's
"break" statement is only occasionally used to exit a loop prematurely.

>> In my limited experience the cases where Ada is introduced into a
>> programming environment also introduce lots of other good software
>> engineering practices.  For example, lots of people I know who
>> program in C don't use LINT.   I view it as a deficiency of management
>> and not of the language that they don't use available tools.

I don't use LINT. I use compilers that check certain things I want checked,
like "no prototypes in scope".  LINT does not catch the kinds of mistakes
that I make.  How many ADA programmers do you know of use LINT?

>   This is certainly true; Brooks and others have noted that the good
>   software engineering practices which are routinely introduced in
>   conjunction with the Ada language are responsible for more of the 
>   resulting improvements than the fact that the Ada language was

Well, these practices are certainly NOT being introduced in the universities
(at least not here).

>   introduced.  However, we cannot disregard that fact that Ada was
>   specifically designed to provide maximal support for the software 
>   engineering process.  C, on the other hand, was designed to provide

No, ADA was designed to have everything. The fact that it (or some subset
of it) can be used to do software engineering doesn't mean it was designed
to do it.  Software engineering can be done in any language, including C.

>   maximal support for the compilation process.  Since compilers and 
>   the CPU power required to operate them come far more cheaply than 
>   programmers, and especially in view of the fact that better error
>   prevention is worth much more than faster compilation, it would seem
>   that the tradeoff made by Ada is certainly the one to be preferred.

The "tradeoff made by ADA?" Do you mean poor code generation versus code that
can be read by non-programmers? Or do you mean the language syntax that
creates nightmares for maintenance? (Does Ada allow you to redefine the
precedence of operators?) Or maybe you mean "language that the government
will use" versus "language that non-government related software companies
will use"?

		Scott MacHaffie

Re: problems/risks due to programming language

[William Thomas Wolfe, 2847]

From machaffi@fred.cs.washington.edu (Scott MacHaffie):
>>   code associated with the else part.  Thus, we have an inconsistency
>>   in C's design: with one flow-of-control construct (the switch), it is
>>   necessary to use a dangerous GOTO to achieve normal processing, whereas
> 
> No, it is necessary to use a statement to indicate that the current case
> statement is finished...like an "end case" or the next "when => " in ADA.

   Such a statement already exists: either the next "case Value:", or 
   the } which ends the switch.  Why is it necessary to use a "break"?
 
>>   with a similar flow-of-control construct (the if-else), the default is
>>   reversed.  Given such a language design, it should not surprise anyone
>>   that programmers become confused, particularly when the constructs are
>>   being used together. 
> 
> Some programmers become confused -- good programmers, and software 
> engineers, don't.

   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. 

>>   This is certainly true; Brooks and others have noted that the good
>>   software engineering practices which are routinely introduced in
>>   conjunction with the Ada language are responsible for more of the 
>>   resulting improvements than the fact that the Ada language was
> 
> Well, these practices are certainly NOT being introduced in the 
> universities (at least not here).

   In that case, I strongly suggest that you immediately bring 
   this fact to the attention of the software engineering faculty 
   at washington.edu.  At other universities (e.g., Clemson), Ada
   *is* introduced in conjunction with software engineering.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: problems/risks due to programming language

[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

Re: problems/risks due to programming language

[David Kassover]

In article <5498@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (Richard A Hammond) writes:
...
>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.


Way back in the mists of time, before FORTRAN77 and Ratfor were
inflicted on us, I was doing computer programming with a fortran
preprocessor variously called FLEXTRAN, FLEX, FLECS, etc.
 
One of the features of this preprocessor was that it provided 4
varieties of case statement, as well as an IF-THEN-ELSE
construct.  All four had optional catchall statements.
 
We had the SELECT and the CONDITIONAL.
 
SELECT was similar to Ada Case.  One selected an expression, and
specified cases for each.  CONDITIONAL was more like an
IF-THEN-ELSE, and was not strictly necessary.  That is, one
entered the conditional, and executed the code associated with
the first of a list of conditions that was true.
 
There were also the ENTER SELECT and the ENTER CONDITIONAL.
Exactly like SELECT and CONDITIONAL, except that once a case was
selected, control passed through to all subsequent cases,
including a catchall if present.  Similar to the C Switch.

I have no idea why someone went to the trouble of providing more
than a functionally complete set of control structures, but it
was very handy, *IF* the programmer didn't choose the wrong one
by mistake, or got confused as to which one he wanted.
 
Oh, well, nothing has changed...
 
By the way, if anyone could suggest a way to make a preprocessor
whose output would be legal FORTRAN *and* a correct program,
if the fortran language did not have an ASSIGNED GOTO construct,
I would appreciate it.  My mind doesn't work that way...

Re: problems/risks due to programming language

[Jeff Lawhorn]

It seems to me that if the program in question had been
thoroughly tested it would not matter if it had been written in
C or Ada or Pascal or anything else.  The bug would have been
found, and AT&T's network would not have been knocked off the
air.  In **EVERY** language it is possible to write valid code
that does not do what the programmer wants.  This is why every
possible code path should be tested before it is placed into a
production system.  Let's hope that AT&T didn't learn not to use
C or Ada or whatever, but that they learned to test their
software better before using it in a production system.
--
Jeff Lawhorn
lawhorn@opti.uucp
opti!lawhorn@berick.uucp
ucsd!sdsu!berick!opti!lawhorn

Re: problems/risks due to programming language

[Douglas Miller]

In article <10811@june.cs.washington.edu>, machaffi@fred.cs.washington.edu (Scott MacHaffie) writes:
> In article <8103@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>>   introduced.  However, we cannot disregard that fact that Ada was
>>   specifically designed to provide maximal support for the software 
>>   engineering process.  C, on the other hand, was designed to provide
> 
> No, ADA was designed to have everything.  The fact that it (or some subset
> of it) can be used to do software engineering doesn't mean it was designed
> to do it.

Valid but utterly vacuous point, as ADA *was* designed to provide maximal
support for software engineering.  I suppose its possible that another
(hidden?) design goal was to "have everything".  So what?

>    Software engineering can be done in any language, including C.

Irrelevant --- the claim here is that ADA provides *maximal* *support* for
the software engineering process.  Like, if I said "Air travel is the
fastest way to get to another city" and you said "You don't have to go by
`plane.  You could go by car, or even on foot", then I'd look at you with a
slightly glazed expression, right?   Sorry to labor this, but I've seen the
above point made *too* many times.

Re: problems/risks due to programming language

[Dan L. Pierson]

In article <5017@csv.viccol.edu.au> dougcc@csv.viccol.edu.au (Douglas Miller) writes:
   Valid but utterly vacuous point, as ADA *was* designed to provide maximal
   support for software engineering.  I suppose its possible that another
   (hidden?) design goal was to "have everything".  So what?

   >    Software engineering can be done in any language, including C.

   Irrelevant --- the claim here is that ADA provides *maximal* *support* for
   the software engineering process.  Like, if I said "Air travel is the
   fastest way to get to another city" and you said "You don't have to go by
   `plane.  You could go by car, or even on foot", then I'd look at you with a
   slightly glazed expression, right?   Sorry to labor this, but I've seen the
   above point made *too* many times.

This bit of ADA mythology (or dogma) has also been made too many times
for me to remain silent.  Yes, ADA did have a goal of maximal support
for the software engineering process.  However other goals (and the
committee requirements and design process) largely subverted that goal
by producing an excessively large, over-specified monster.

You can certainly do software engineering in ADA, it is in most ways a
better language for the purpose than C, but other languages such as
Modula-3, Eiffel, and maybe Turing provide at least the software
engineering benefits of ADA (though not all the "nifty" features*) in
languages that are small enough to be useable, learnable, teachable,
and efficiently implementable in less than a decade.

I'm not interested in another C vs. ADA vs. my-favorite-language war,
but I'm just plain tired of the line that ADA is equivalent to
software engineering because the DOD and those who base their careers
on it say so.

*In fact, some of these "nifty" features present more opportunity for
misuse, and thus software engineering drawbacks, than benefits.
Operator overloading comes to mind...
--

                                            dan

In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@encore.com

Re: problems/risks due to programming language

[David Kassover]

Wow, we are getting vicious, aren't we?

In article <PIERSON.90Feb22110501@xenna.encore.com> pierson@encore.com (Dan L. Pierson) writes:
>In article <5017@csv.viccol.edu.au> dougcc@csv.viccol.edu.au (Douglas Miller) writes:
>   Valid but utterly vacuous point, as ADA *was* designed to provide maximal
>   support for software engineering.  I suppose its possible that another
>   (hidden?) design goal was to "have everything".  So what?
>
>   >    Software engineering can be done in any language, including C.
...
>
>This bit of ADA mythology (or dogma) has also been made too many times
>for me to remain silent.  Yes, ADA did have a goal of maximal support
>for the software engineering process.  However other goals (and the
...
>but I'm just plain tired of the line that ADA is equivalent to
>software engineering because the DOD and those who base their careers
>on it say so.
>Internet: pierson@encore.com

Ada vs C vs Pascal vs.... and mythology
 
 
I think what I am going to write as follows are verifyable facts.
I am not responsible for things not turning out as they were
intended...
 
 
Ada was designed by a committee (!!???  we can argue the merits
of that elsewhere) which had certain aspects of the computer
programming process that they wanted to address.  Many of these
aspects were based on real life experience  (E.G. real-time
programming, needing to acknowledge error conditions that make
continuance undesirable)  The committee succeeded in answering
most of the desires, and where there was an irresolvable
conflict, chose.  Therefore, we have goto statements, no
conditional compile, etc.

Pascal was designed by an individual who had as his primary
concern the production of a testbed from which to teach computer
language design  (or was it computer language compiler design.
NOT THE SAME THING!)  Furthermore, this individual was a
proponent of a restrictive structured programming theory.
Therefore, we have a rather incomplete language with some
extremely annoying features.

C, and Unix, were built, at least initially, by an individual who
wanted to take a crack at building an operating system from
scratch, on a more or less scrapped piece of hardware, while
employed by an employer which was more or less liberal about such
activities.  Therefore we have a language, and OS, which is
simple, and does some things very well indeed, but addresses
other things not at all.


Now, we're back to educated opinion.  Ada, as implemented, did
not achieve all it's goals.  But I submit that it acheived many
of them;  that not all stated goals were even in the original
mix; and that the set of goals was broader in scope than the goal sets
of either C or Pascal.

A long time ago, when I knew less than I do now, I said that Ada,
as specified, was the embodiment of what a Pascal programmer
thought a Cobol programmer ought to have at his disposal.  I
stand by that statement today.  But still, for me, as a programmer
working on a production job, Ada is the language of choice, all
other things being equal  (which they rarely are).  For a
personal programming job that is not likely to ever be touched by
other than me, the language of choice is FORTRAN, simply because
that is the first computer programming language I learned after
BASIC (a very long time ago!), again all other things being equal.


I would like to see this newsgroup return to discussions of Ada
and implementations of Ada.  Or maybe we could create a
sub-newsgroup like comp.lang.flame??  8-)

Dave

Re: problems/risks due to programming language

[Erland Sommarskog]

Dan L. Pierson (pierson@encore.com) writes:
>*In fact, some of these "nifty" features present more opportunity for
>misuse, and thus software engineering drawbacks, than benefits.
>Operator overloading comes to mind...

Of course you could do really ugly things with operator overloading,
particulary in combination with RENAME. But in a good software
engineering environment with code reviews you would never be allowed 
to do them.

Operator overloading is an important feature. No wonder that
both C++ and Eiffel has incorporated varities thereof. (Eiffel
doesn't really have overloading, but well infix routines.)

Why? Well, in my daily work, which is in Pascal, I have to struggle
with quadword integers. An expression like a := a + (b*c) DIV d + e
becomes when a, b and e are quads:

    a := Add_quads(a, Add_quads(
           Div_quads(Mult_quads(b, Conv_lw_to_qw(c)), Conv_lw_to_qw(d)), e))

which is not very readable. Even more important is that if have
written the standard integer version above and later discover that
I have to change to quads, I don't have to change any existing code.
(Of course the example above can be alleviated in various ways. The
routines used are the standard routines at the site I am on.)
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se

Re: problems/risks due to programming language

[Mike Harrison]

In article <5017@csv.viccol.edu.au> dougcc@csv.viccol.edu.au (Douglas Miller) writes:
>Valid but utterly vacuous point, as ADA *was* designed to provide maximal
>support for software engineering.  I suppose its possible that another
>(hidden?) design goal was to "have everything".  So what?
>
Wrong ! - Ada was designed primarily to save DoD money, secondarily to support
very long in-service life software (by simplifying the maintenance process), 
with all kinds of other goodies as a tertiary aim.

Way back in (about) 1975 HOLWG showed that DoD was spending huge sums on s/w 
in embedded systems, which were programmed in >300 languages (including ~ 70
different, often incomptible versions of JOVIAL).
The idea of Ada (was Ironman etc.) was to provide a *single* language in which
almost all embedded operational military s/w would be written, then it would 
only be necessary to keep one kind of programmer - an Ada programmer.

Those of us working on Ada and its environments (things which led to Stoneman)
in those days were serious about this people portablity (which was the prime
motivation for the NO SUBSETS, NO SUPERSETS policy).

Whether Ada, its implementers, DoD or anyone else succeded in these aims is a
matter of personal taste, but I believe that the aims were good and the spirit
which motivated most of the early workers was laudable.

[Whatever became of paths and boxes?]

Mike,




Michael P. Harrison - Software Group - Inmos Ltd. UK.
-----------------------------------------------------------
UK : mph@inmos.co.uk             with STANDARD_DISCLAIMERS;
US : mph@inmos.com               use  STANDARD_DISCLAIMERS;

Re: problems/risks due to programming language

[Douglas Miller]

In article <4174@ganymede.inmos.co.uk>, mph@lion.inmos.co.uk (Mike Harrison) writes:
> In article <5017@csv.viccol.edu.au> dougcc@csv.viccol.edu.au (Douglas Miller) writes:
>>Valid but utterly vacuous point, as ADA *was* designed to provide maximal
>>support for software engineering.  I suppose its possible that another
>>(hidden?) design goal was to "have everything".  So what?
>>
> Wrong ! - Ada was designed primarily to save DoD money, secondarily to support
> very long in-service life software (by simplifying the maintenance process), 
> with all kinds of other goodies as a tertiary aim.

I know, these were the *requirements*.  ADA was *designed* to meet these
requirements by providing maximal support for software engineering.

Alternatively I could argue that the requirements you mention basically
define what software engineering is, and you are just nitpicking.

Re: problems/risks due to programming language

[Mike Percy]

From article <8103@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ):

[Ada is great, Ada is wonderful, nothing can beat Ada, if you don't program 
 in Ada you are stupider than worm-slime, blah blah blah]

I've used Ada Bill, I even liked it. But, I am really getting tired of reading
your diatribes against every other programming language, of reading your
praises of Ada to the exclusion of all others.  I use the language I feel
is best for the particular problem at hand.  I drop into assembly to 
optimize a speed-critical section of code.  I use C for portability (right,
I know, there are n fully verified  Ada compilers running of x different
machines, so how can Ada not be portable?) and speed of coding (my speed
is higher in C than in Ada or any other language, this is subject to
change of course), I use COBOL at work because that is the language the
systems I maintain, I use a quasi-4GL when I can to spit out 3GL code. 
SOmetimes I use SNOBOL, Lisp, or Prolog, or Pascal.

I've seen some Ada code that must have been written by brain-damaged idiots.
And I've seen some beautifully written assembly.

The point is, that the programming practices are what makes the difference.
It is entirely reasonable to engineer software in C or Prolog or...
Just as it is reasonably easy to mangle Ada.  Granted, Ada lends itself
to good software engineering practices, probably you could even say that it
encourages it. However, it does not guarantee it, nor does the failure to
use Ada preclude good software engineering practices.

My guess is that Ada will gain a load of users and their respect when there 
is a Microsoft Ada or better yet (or worse yet) a Turbo Ada.

Anyway please try to keep your pro-Ada, anti-everything-else stuff in check. 

-- 

'I just couldn't convince the voters that Dukakis was Greek for
"Bubba".' -- Lloyd Benson explaining why the Democrats didn't carry
Texas

Re: problems/risks due to programming language

[Douglas Miller]

In article <8103@hubcap.clemson.edu>, billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:
>    Ada, on the other hand, is consistent: in both the if and case statements,
>    the default is to exit the construct once the code associated with the
>    specified situation has been executed.  Ada also provides the exit
>    statement, a restricted GOTO which permits a loop to be exited early,
>    but this construct is not used (as is C's break) on a routine basis.  

Huh?  Surely EXIT is the only and sensible way to exit a simple loop?  Why
do you call EXIT a `restricted GOTO'?  This makes as much sense to me as
describing a statement as a performing a `restricted GOTO' from the
previous statement.

Re: problems/risks due to programming language, stories requested

[David Kassover]

In article <5432@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (Richard A Hammond) writes:
>In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes:
>
>>For a research project I am collecting information about the risk of
>>choosing the wrong programming language. In particular I am looking
>>for problems that could have been avoided if another (a better)
>>programming language would have been used.
>
>>I know of these three such stories:
>	...
>>     3. The AT&T breakdown a month ago was caused by a break statement
>>	in C. See the following mail (multiple forwarding headers deleted):
>
>What other programming language?  Only one without any GOTO or restricted
>GOTO (e.g. exit, break, ...).  This leaves out Ada!!!!!!
>
>Similar bug in Ada: 	(Cut down for posting, but gives the flavor)
>
>In my limited experience the cases where Ada is introduced into a
>programming environment also introduce lots of other good software
>engineering practices.  For example, lots of people I know who
>program in C don't use LINT.   I view it as a deficiency of management
>and not of the language that they don't use available tools.
 
OK.  First, I apologise for mis-representing the "classic"
FORTRAN goof  (There's one that's actually ambiguous to the
compiler, involving FORMAT statements and Hollerith constants,
but I can never remember it)

Now, AT&T breakdown:
 
You show how this could happen in Ada.  Ok, it could.  But ada
allows one to "name" loops, and use those names in exit
statements, especially useful when you want to break out of an
inner and an outer loop.  In your example, you didn't do so,
since the C code could not.  But you could have.
 
Looking back at the last 20Klines of Ada I've written recently,
I've used named loops roughly twice.  Specifically to avoid
ambiguity to me when I look at the code, but it helps make sure
I did it right, too.
 
You go on to bemoan the lack of use of LINT.  I submit that,
since we're not dependent on underpowered pdp9's or 11's anymore,
then LINT should be built into the compiler, or there as the
default option  (to be turned off at the user's risk)

And onward, to problems that are exacerbated by the language.  

Time and again, my C development people spend oodles of effort
tracking down something that ends up being resolved by
discovering a header file that was changed, but not *all* of the
dependent code was recompilied.  Use make, you say?  Sure, but
someone's got to write the make script, whose language is no gem,
either.
 
Ada's insistence on specification recompile (and lack of a
include processor) cause the dependency tree to be built and
modified automatically.  (in Vax ada, you can enter "foreign
language" object modules into the library, so they, too, can
participate in obsolescence analysis.  I don't know if anyone
else provides this, or how well it works)
 
 
On a par in terms of frequency with the above is the case of the
non-catchalled case statement.  In ada, if you have a case
statement of an enumerated type, and you do not provide a case
for every member of the type or a when others => clause, the
compiler signals an error.  No, this doesn't stop someone putting
a when others => null; in, but most of us either use the compiler
to remind us to put in an appropriate case or cause a fatal error
to occur in the catchall, the theory being that it will blow up
in testing, and the appropriate case added.
 
Finding this thing in C is a bear, especially when, if your code
is like mine, three quarters of it is conditional compile based
on flags set in a header file somewhere.
 
And just as a final note:  I have demonstrated many times that it
is possible to write FORTRAN in Ada.  About the only places I
haven't been able to do so, if I really wanted to, have been APL
and assembler.  That doesn't mean that either Ada or FORTRAN are
valueless. 

Re: problems/risks due to programming language, stories requested

[Richard A Hammond]

In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes:

>For a research project I am collecting information about the risk of
>choosing the wrong programming language. In particular I am looking
>for problems that could have been avoided if another (a better)
>programming language would have been used.

RE: AT&T example
OK folks, I was not trying to say that C was as good as Ada,
I merely pointed out that in both C and Ada one could have a
legal program that had a restricted goto (C "break", Ada "exit")
inside an if, and that neither language's compilers could detect
whether the programmer really wanted that or not.  This, to my
mind, makes the example not fit the class that was requested,
of cases where a different language would have prevented the
problem.


In article <5458@crdgw1.crd.ge.com> kassover@jupiter.crd.ge.com (David Kassover) writes:
...
>Time and again, my C development people spend oodles of effort
>tracking down something that ends up being resolved by
>discovering a header file that was changed, but not *all* of the
>dependent code was recompilied.  Use make, you say?  Sure, but
>someone's got to write the make script, whose language is no gem,
>either.

The oodles of time is an exageration, since, painful though it
might be, writing the make script would solve the problem once
and for all.  This suggests that the cost to find the numerous
problems is less than to write a make script.  By the way, there are
tools available to automatically generate most of the makefile.
Besides, if you have a make script you can cause lint to run
automatically, which is a nice side benefit.

>Ada's insistence on specification recompile (and lack of a
>include processor) cause the dependency tree to be built and
>modified automatically.  (in Vax ada, you can enter "foreign
>language" object modules into the library, so they, too, can
>participate in obsolescence analysis.  I don't know if anyone
>else provides this, or how well it works)
 
And it is a real pain when the compiler has a bug in the implementation,
as does the Ada compiler we're using.  If you change a generic body
it messes up its internal information and you end up recompiling
everything, so we end up avoiding the built-in "make" of Ada and
writing make scripts to get the proper recompilations done.
Maintaining the make scripts costs less time than recompiling
everything every time you change a generic body.
Building everything into the compiler does have disadvantages.

>On a par in terms of frequency with the above is the case of the
>non-catchalled case statement. ...
 
>Finding this thing in C is a bear, especially when, if your code
>is like mine, three quarters of it is conditional compile based
>on flags set in a header file somewhere.

So, in Ada you either write incomplete code (because the compiler
will catch it) or you raise an exception(I imagine) in the "others"
case.  I don't see why you can't  adopt the second solution in C.
If it happens often, adopt a coding style to minimize it, always
put "default: abort();" in your switch statements.

Your complaints remind me of the old chinese saying (Rich's paraphrase)
Fooled once, shame on the language which fooled you.
Fooled twice, shame on you.

Rich Hammond

Re: problems/risks due to programming language, stories requested

[David Kassover]

In article <5464@crdgw1.crd.ge.com> hammondr@sunroof.crd.ge.com (Richard A Hammond) writes:
>In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes:
>
>>For a research project I am collecting information about the risk of
>>choosing the wrong programming language.
>In article <5458@crdgw1.crd.ge.com> kassover@jupiter.crd.ge.com (David Kassover) writes:
>...
>>Time and again, my C development people spend oodles of effort
>>tracking down something that ends up being resolved by
>>discovering a header file that was changed, but not *all* of the
>>dependent code was recompilied.  Use make, you say?  Sure, but
>>someone's got to write the make script, whose language is no gem,
>>either.
>
>The oodles of time is an exageration, since, painful though it
>might be, writing the make script would solve the problem once
>and for all.
>
"Oodles" is a rather imprecise term.  I apologize.  But you
aren't here.  Almost time I visit my development people, they are
chasing some sort of bug that was traced to this case, or a
missing catchall.  I may have sampling error problems, I admit it.
>>Ada's insistence on specification recompile (and lack of a
>>include processor) cause the dependency tree to be built and
>>modified automatically.  (in Vax ada, you can enter "foreign
>>language" object modules into the library, so they, too, can
>>participate in obsolescence analysis.  I don't know if anyone
>>else provides this, or how well it works)
> 
>And it is a real pain when the compiler has a bug in the implementation,
>as does the Ada compiler we're using.
>...
If your compiler has a bug (Since Ada is thoroughly standardized,
one standard, no extensions, no subsets) then you should get it
fixed or get a different compiler.

>Maintaining the make scripts costs less time than recompiling
>everything every time you change a generic body.
>Building everything into the compiler does have disadvantages.
>...
Well, you're there, and I'm not.  But attempting to do a
professional job with amateur's tools, or amateur quality tools,
is likely to be frustrating, among other things.  This is not a
problem with the language, it's a problem with the implementation
your stuck with.


By the way, the product line I am dealing with is supported on
more than 20 different operating systems, only some of which are
Unix, or Unix-like, some of which do not offer a make-analog, and
even of the ones which do, the make scripts have to be (only
sometimes subtly) different.  I simply do not have time, nor the
charter, to implement make for everybody
>
>>On a par in terms of frequency with the above is the case of the
>>non-catchalled case statement. ...
> 
>>Finding this thing in C is a bear, especially when, if your code
>>is like mine, three quarters of it is conditional compile based
>>on flags set in a header file somewhere.
>
>So, in Ada you either write incomplete code (because the compiler
>will catch it) or you raise an exception(I imagine) in the "others"
>case.
>...
No, I didn't write incomplete code and wait for the compiler to
catch it.  (I've used this technique elsewhere, though).  It is
common, in the ada I have seen, to define in a package
specification an enumerated type.  Later on, someone adds an
element to the type.  (e.g. support for a different type of data
structure, or even, as is the case, add a new package to the
system.  (this system keeps track of the names of it's packages,
in order to generate traceback information during runtime user
errors))

The code in the package body contains a case statement on the
enumerated type.  It was not created incomplete, but it was
RENDERED incomplete by the insertion of a new element.  Since
recompilation is of this body is forced, without having to
remember to modify the make script (we've already forgotten to
modify the package body, remember), this error is fixed before
the module gets out of unit test.

this is not to say that the compilable code in the case statement
is not erroneous, but falling off the end of the case statement
is probably at least as bad.  That is, some human has to exert
effort to allow the case statement to be fallen through, rather
than it being allowed to happen.
>
>If it happens often, adopt a coding style to minimize it, always
>put "default: abort();" in your switch statements.
>
>...
This is the real world.  I have little time to fight with my
people over personal style, and I don't want to be viewed as a
tin pot tyrant over stylistic issues.  My concerns are getting
the product out there, with as few errors as possible.  Ada
appears to help in this regard more than C does.  I'm sure you
and your employers have a somewhat different agenda.
 

Dave Kassover

Re: problems/risks due to programming language, stories requested

[David Kassover]

by the way, are we discussing Ada here, or structured
programming?
 
I've already made up my mind (LONG AGO) about one of them... :-)

Dave

Re: problems/risks due to programming language, stories requested

[Thomas Vachuska]

    Maybe I am missing the point here, but to the best of my knowledge
Ada "exit" statement is allowed only within a "named loop|loop" statement
(unless it appears in a "subprogram|package|generic|task|accept body" which is 
enclosed within that "loop" statement, to be precise).  And as far as I know
similar restrictions apply for the use of the C "break" statement which 
terminates the execution of either the "while|do|for" or "switch" statement.  
Neither of these are to abandon execution of an "if" statement block.
    I would agree that it is easier to get in trouble in the following 
situation in C which does not have a counterpart in Ada since Ada's "exit"
exits ONLY the "loop" statement.

    switch (trouble) {
        case PROGRAMMER_SCREW_UP: 
            for (;;) {
                break;    /* intended for exiting the "switch", BUT... */
            }
        case ...
        .
        .
    }


Thomas Vachuska  (-- Ada Addict)

Re: problems/risks due to programming language, stories requested

[Mark Brader]

Gerald Baumgartner (gb@cs.purdue.EDU) writes in many groups:
> There is the famous story that a Mariner probe got lost
> because of the Fortran statement `DO 3 I = 1.3' (1.3 instead
> of 1,3) ... It is a nice story but, as far as I know, NASA used
> Jovial at that time and not Fortran.

Just for the record, the above was definitively shown to be fictional
according to authoritative references given in comp.risks (= Risks Digest),
issue 9.75 (I hear), not too many months ago.  There is at least one
textbook that states it as truth; this is wrong.  The actual reason for
the loss of Mariner I was an error in code used in recovering from a
hardware failure; the code had been based on handwritten equations, and
in transcribing one of these, an overbar was deleted from one letter.

A story which may have been the true origin of the "DO statement myth"
was posted fairly recently in alt.folklore.computers; the article
cited a program at NASA that did enter production use with a dot-for-comma
bug in a DO statement, but it wasn't a spacecraft flight control program.
(I didn't save the details and would be happy to see them again.)

Followups directed to alt.folklore.computers.

-- 
Mark Brader			"I'm not going to post a revision: even USENET
utzoo!sq!msb, msb@sq.com	 readers can divide by 100."	-- Brian Reid

This article is in the public domain.

Re: problems/risks due to programming language, stories requested

[Bill Leonard]

In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald Baumgartner) writes:

   I received the following on AT&T's famous bug (and have deleted multiple 
   forwarding headers):

   | | Subject: AT&T Bug
   | | Date: Fri Jan 19 12:18:33 1990
   | | 
   | | This is the bug that cause the AT&T breakdown
   | | the other day (no, it wasn't an MCI virus):
   | | 
   | | In the switching software (written in C), there was a long
   | | "do . . . while" construct, which contained
   | |    a "switch" statement, which contained 
   | |       an "if" clause, which contained a
   | |          "break," which was intended for
   | |       the "if" clause, but instead broke from
   | |    the "switch" statement.
   | | 

           Again it looks like this bug wouldn't have occurred in another
           programming language.

I can't resist saying that this last statement seems to me to be utter
nonsense.  What programming language (read, compiler) can read the
programmer's mind and tell what he meant?  The use of the "break" statement
was a logic error (actually, it sounds like it was a lack of knowledge of
the language, since "break" does not apply to "if").  I can't imagine a
programming language that could discern this type of error.  [If I use
WHILE instead of IF, for instance, I can expect some things to work and
some not.  Yet I seriously doubt any compiler could possibly detect this
error.]

I certainly think programmers often choose an inappropriate language, but I
shy away from anecdotal stories like these because they seem (to me) to
spread a lot of misinformation.  Unless you implement a project in multiple
languages, it is nothing more than a guess to say what would have happened
if the project had been implemented in some other language.  Perhaps you
would have discovered an even more serious flaw in that language, or you
might simply find it was no better or worse than the one you chose, just
different.

Most of the stories I have heard along these lines all struck me as missing
the point: how well was the program tested?  Were there code reviews?
Design reviews?  All of these techniques are proven to reduce errors.  Most
of the errors in these stories (e.g., the infamous dot-versus-comma one)
should have been found with even rudimentary testing.

Use of an inappropriate language is no excuse for abandoning other techniques
of good software engineering.
--
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.csd.harris.com or hcx1!bill@uunet.uu.net

Re: problems/risks due to programming language, stories requested

[Paul Snively]

In article <BILL.90Feb27143004@hcx2.ssd.harris.com> bill@ssd.harris.com 
(Bill Leonard) writes:
> In article <9790@medusa.cs.purdue.edu> gb@cs.purdue.EDU (Gerald 
Baumgartner) writes:
>            Again it looks like this bug wouldn't have occurred in another
>            programming language.
> 
> I can't resist saying that this last statement seems to me to be utter
> nonsense.  What programming language (read, compiler) can read the
> programmer's mind and tell what he meant?  The use of the "break" 
statement
> was a logic error (actually, it sounds like it was a lack of knowledge of
> the language, since "break" does not apply to "if").  I can't imagine a
> programming language that could discern this type of error.  [If I use
> WHILE instead of IF, for instance, I can expect some things to work and
> some not.  Yet I seriously doubt any compiler could possibly detect this
> error.]
> 
> I certainly think programmers often choose an inappropriate language, 
but I
> shy away from anecdotal stories like these because they seem (to me) to
> spread a lot of misinformation.  Unless you implement a project in 
multiple
> languages, it is nothing more than a guess to say what would have 
happened
> if the project had been implemented in some other language.  Perhaps you
> would have discovered an even more serious flaw in that language, or you
> might simply find it was no better or worse than the one you chose, just
> different.
> 
> Most of the stories I have heard along these lines all struck me as 
missing
> the point: how well was the program tested?  Were there code reviews?
> Design reviews?  All of these techniques are proven to reduce errors.  
Most
> of the errors in these stories (e.g., the infamous dot-versus-comma one)
> should have been found with even rudimentary testing.
> 
> Use of an inappropriate language is no excuse for abandoning other 
techniques
> of good software engineering.

I don't think that anyone's claiming that it is an excuse; I believe the 
point was that some languages applied to some tasks lend themselves to 
error more than another language applied to the same task.  If you wish to 
interpret the above story as a rather pointed jab at the C programming 
language, and object to C being treated that way, that's fine, but please 
just say so.

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.  I believe that it's C's historical looseness that 
is simultaneously its greatest weakness, when it leads to errors like 
this, and its greatest strength--C doesn't restrict you; C is mean and 
lean; C is close to the hardware; real programmers use C; even, God help 
us, C is the only language you need!  We all know C programmers whose 
machismo is thus huffed and puffed up (another of my personal opinions is 
that the per capita arrogance of C programmers far outweighs the per 
capita arrogance of any other language-aficionado group).

Now to get back to the important point: what language would have been 
better for the task in question?

Well, I hate to say it, but it's extremely unlikely that such an error 
would have been made in Pascal, since Pascal doesn't require you to 
explicitly break from case...of constructs.

Before the flames start, let me just add: no, I don't necessarily prefer Pascal over C for all tasks.  I generally attempt to choose the right tool for the job, rather than falling into the "when all you have is a hammer, everything looks like a nail" trap.

Standard Disclaimer.

Re: problems/risks due to programming language, stories requested

[Jason Coughlin]

From article <6960@internal.Apple.COM>, by chewy@apple.com (Paul Snively):
> 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.

	Gee, if you read the language defn you'd know exactly when break
applies and when break doesn't.  It seems to me that it is the
programmer's responsibility to know the language in which he is going to
implement said project -- it's not necessarily the language's responsibility
to know the programmer didn't read the defn.

> Well, I hate to say it, but it's extremely unlikely that such an error 
> would have been made in Pascal, since Pascal doesn't require you to 
> explicitly break from case...of constructs.

	And without knowing the project, you have no business making the
assertion that Pascal was better than C [especially on a Unix box] or
that C was better than Pascal [especially on a VMS box].
-- 
Jason Coughlin ( jk0@sun.soe.clarkson.edu , jk0@clutx )
"Every jumbled pile of person has a thinking part that wonders what the
part that isn't thinking isn't thinking of." - They Might Be Giants

Re: problems/risks due to programming language, stories requested

[Barry Margolin]

In article <1990Feb28.213543.21748@sun.soe.clarkson.edu> jk0@image.soe.clarkson.edu (Jason Coughlin) writes:
>	Gee, if you read the language defn you'd know exactly when break
>applies and when break doesn't.  It seems to me that it is the
>programmer's responsibility to know the language in which he is going to
>implement said project -- it's not necessarily the language's responsibility
>to know the programmer didn't read the defn.

What would you say if a car designer used a similar excuse: Gee, if you'd
read the owner's manual for the 6000SUX you'd know that you have to turn
the radio off before stepping on the brake pedal.  It seems to me that it
is the driver's responsibility to know the car he's driving -- it's not
necessarily the manufacturer's responsibility to know that the driver
didn't read the manual.

Yes, it's the resposibility of the programmer to know the language.  But
it's the responsibility of language designers to design languages
reasonably.  If programmer-friendliness weren't an issue we'd still be
programming in machine language.
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar

Re: problems/risks due to programming language, stories requested

[Richard A Hammond]

Slowly, and carefully, for Bill Wolfe's understanding, let's go through this
once more.

The original article asked for examples of cases where using a different
language would have prevented the error.  He gave 3 examples, one of
which was:
   | | Subject: AT&T Bug
   | | Date: Fri Jan 19 12:18:33 1990
   | | 
   | | This is the bug that cause the AT&T breakdown
   | | the other day (no, it wasn't an MCI virus):
   | | 
   | | In the switching software (written in C), there was a long
   | | "do . . . while" construct, which contained
   | |    a "switch" statement, which contained 
   | |       an "if" clause, which contained a
   | |          "break," which was intended for
   | |       the "if" clause, but instead broke from
   | |    the "switch" statement.

I claim that this information is insufficient to find C guilty in this case.
This is not to say that you can't find examples in C of such problems.
To name a few:

1) Comments with Begin/End delimiters can easily hide code if one leaves
   out the end comment delimiter.  Particularly bad if the compiler doesn't
   warn about nested comments.  This also applies to Pascal, CMS-2, JOVIAL, ...

2) Writing :	if ( a = b )
   rather than:	if ( a == b )

3) Leaving out the "break" at the end of a case.

All these are directly caused by C's language design and another language
would avoid one or more of them (Ada avoids them all).

If the explanation for the AT&T bug was:

we originally had:		we changed it to:
	case ...:		case ...: if (...) {
		stmts_a				stmts_a;
		break;				break;	 -- should have removed
					   }
					   stmts_b;

Then I would agree that it is possible to follow Bill's argument and
assign the bug to the language, although even there it is a bit of a stretch.

But, the explanation is "... a "break," which was intended for the "if" clause."
Which doesn't support any conclusion other than the programmer didn't know
the language.

Why re-hash this?  Well, I'm tired of Bill Wolfe's arguments which run:

We know that Communism is evil.  We know that they had a bad reactor accident.
Therefore, changing to capitalism would have prevented the reactor accident!

I suggest that Bill needs some more elementary logic courses if he really thinks
that the statement of the AT&T bug supports his conclusion.

It would be very helpful if the original poster (from Purdue) explained why
he thought that the bug statement supported assigning it to the class of bugs
prevented by using a different language.

I agree with Bill that C does not provide very good support for the software
engineering process.  I think the examples I gave above are clear examples,
the AT&T bug statement is not.

Rich Hammond

Re: problems/risks due to programming language, stories requested

[William Thomas Wolfe, 2847]

From hammondr@sunroof.crd.ge.com (Richard A Hammond):
%    | | In the switching software (written in C), there was a long
%    | | "do . . . while" construct, which contained
%    | |    a "switch" statement, which contained 
%    | |       an "if" clause, which contained a
%    | |          "break," which was intended for
%    | |       the "if" clause, but instead broke from
%    | |    the "switch" statement.
> 
> Which doesn't support any conclusion other than the programmer didn't know
> the language.

   Not exactly.  There is a lack of orthogonality in that similar
   flow-of-control constructs do not terminate in similar ways.  If
   one is using the if statement, termination is automatic.  If one 
   is using the switch statement, a break is required.  It is this
   lack of orthogonality which leads to potential problems.


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: problems/risks due to programming language, stories requested

[Richard A Hammond]

In article <8211@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From hammondr@sunroof.crd.ge.com (Richard A Hammond):
>%    | | In the switching software (written in C), there was a long
>%    | | "do . . . while" construct, which contained
>%    | |    a "switch" statement, which contained 
>%    | |       an "if" clause, which contained a
>%    | |          "break," which was intended for
>%    | |       the "if" clause, but instead broke from
>%    | |    the "switch" statement.
 
>> Which doesn't support any conclusion other than the programmer didn't know
>> the language.

>   Not exactly.  There is a lack of orthogonality in that similar
>   flow-of-control constructs do not terminate in similar ways.  If
>   one is using the if statement, termination is automatic.  If one 
>   is using the switch statement, a break is required.  It is this
>   lack of orthogonality which leads to potential problems.
				         ^^^^^^^^^ 
weasel words!!  Potential cause /= actual cause.
Reduced probability /= 0.0 probability

Daggone it Bill, why don't you try to understand?

You're quoting this out of context, the whole point of my posting was
that the statement of the bug does not provide sufficient information
to say that changing the language would have PREVENTED the problem.

I gave 3 other examples (of C code problems) where the bug was one that
would have been PREVENTED by use of Ada.

Rich Hammond

Re: problems/risks due to programming language, stories requested

[John Boone]

In article <8211@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:


>   Not exactly.  There is a lack of orthogonality in that similar
>   flow-of-control constructs do not terminate in similar ways.  If
>   one is using the if statement, termination is automatic.  If one
>   is using the switch statement, a break is required.  It is this
>   lack of orthogonality which leads to potential problems.


	This is a minor flame, but I feel it's necessary since literally 
	millions :-) of CS students worldwide read these news groups and 
	learn from them.  So I think you should be more careful using
	four-syllable words :-)

	Orthogonal means, roughly, "at right angles to" - so I think your
	point is really BECAUSE of orthogonality in the flow-of-control
	constucts [ for C ] which leads to potential problems ... etc.

-- 

   ...........................................................................
   :     J. M. Boone      :                                                  :
   :                      :     Tenacity of purpose for a rightful cause     :

Re: problems/risks due to programming language, stories requested

[Charles E Eaker]

In article <8211@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>From hammondr@sunroof.crd.ge.com (Richard A Hammond):
>%    | | In the switching software (written in C), there was a long
>%    | | "do . . . while" construct, which contained
>%    | |    a "switch" statement, which contained 
>%    | |       an "if" clause, which contained a
>%    | |          "break," which was intended for
>%    | |       the "if" clause, but instead broke from
>%    | |    the "switch" statement.
>> 
>> Which doesn't support any conclusion other than the programmer didn't know
>> the language.
>
>   Not exactly.  There is a lack of orthogonality in that similar
>   flow-of-control constructs do not terminate in similar ways.  If
>   one is using the if statement, termination is automatic.  If one 
>   is using the switch statement, a break is required.  It is this
>   lack of orthogonality which leads to potential problems.

Ok, so the implied orthogonality of Ada means that, without putting
a whole lot of thought into it, I can map the above C outline to
Ada as follows:

  In the switching software (TRANSLATED to Ada), there was a long
   "LOOP" construct, which contained
      a "CASE" statement, which contained 
         an "IF" clause, which contained an
            "EXIT," which was intended for
         the "IF" clause, but instead broke from
      the "LOOP" statement.

and if there's a mistake here, it's because of the lack of orthogonality
of Ada (which we all know is laughable) rather than any misunderstanding
of the language on my part. Right?  Hmm, maybe I'll stop working in Ada
and go back to C. I like the idea of the language taking the wrap for
what some misguided souls have viewed as my mistakes.  But wait! Maybe
I can stick with Ada. All I have to do is show, somehow, that Ada is
not all that orthogonal ... hmm ...

--
Chuck Eaker                                |  eaker@sunbelt.crd.ge.com
Software Engineering Program               |  eaker@crdgw1.UUCP
GE Corporate Research & Development Center |  (518) 387-5964
P.O. Box 8, K-1 3C12 Schenectady, NY 12301 |  8*833-5964

Re: Invalid analogy

[William Thomas Wolfe, 2847]

From eaker@sunbelt.crd.ge.com (Charles E Eaker):
>>   [In C] similar flow-of-control constructs do not terminate in 
>>   similar ways.  If one is using the if statement, termination is
>>   automatic.  If one is using the switch statement, a break is required.  
> 
% [An invalid analogy is attempted:]
%    "LOOP" construct, which contained
%       a "CASE" statement, which contained 
%          an "IF" clause, which contained an
%             "EXIT," which was intended for
%          the "IF" clause, but instead broke from
%       the "LOOP" statement.

   Notice: "similar flow-of-control constructs".  Both the case and 
   the if statements execute different sections of code depending on
   the value of a controlling expression.  A loop is a flow-of-control
   construct, but not one which is similar to the if or case constructs,
   which are so closely related that one is a special case of the other. 

   This extreme similarity, unfortunately, does not extend to C's concept
   of how the two should be supported within the programming language. 


   Bill Wolfe, wtwolfe@hubcap.clemson.edu
 

Re: Invalid analogy

[I Wish]

In article <8222@hubcap.clemson.edu>
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:

> From eaker@sunbelt.crd.ge.com (Charles E Eaker):

>> [In C] similar flow-of-control constructs do not terminate in 
>> similar ways.  If one is using the if statement, termination is
>> automatic.  If one is using the switch statement, a break is required.  

[his example, a nested loop/if/switch/etc.]

> Notice: "similar flow-of-control constructs".  Both the case and 
> the if statements execute different sections of code depending on
> the value of a controlling expression.  [...]

> This extreme similarity, unfortunately, does not extend to C's concept
> of how the two should be supported within the programming language. 

> Bill Wolfe, wtwolfe@hubcap.clemson.edu

I see C's if as an exclusive two-case switch.  If doesn't need break
because fallthrough in an if would be useless -- any code common to the
then and else clauses can be factored out of the if, since there are no
other cases.  "If", as a _special_ _case_ of switch, assumes a break;
would C be better if "then" required a break to prevent fallthrough to
the else?  That would be a consistent way to make them similar.
-- 
"indecipherable strangers handing out inexplicable humiliation and an
 unidentified army of horsemen laughing at him in his head ..."
                                                           -- Douglas Adams
Erik Seaberg (khan@milton.u.washington.edu)

Re: Invalid analogy

[John F Nixon]

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe, 2847 ) writes:

> [Both case and if] statements execute different sections of code
> depending on the value of a controlling expression.  ... the if or
> case constructs ... are so closely related that one is a special case
> of the other. This extreme similarity, unfortunately, does not extend
> to C's concept of how the two should be supported within the ... language.

I was wondering how Bill was going to defend Ada's inclusion of loop/exit :-).
Clearly, it is a violation of the notion of consistency; so now we are
reduced to merely consistency within "similar" constructs.  I would argue that
if consistency is indeed a good thing, it is worth being consistent throughout.

It would be possible to design a language that is so inconsistent one would 
have difficulty programming in it.  I claim neither C nor Ada fall in that
class.  I have written lots of C code, and I cannot *ever* remember leaving
out a break; it is simply not confusing to anyone who understands C.  I have
not written much Ada; I have been confused by Ada, because I do not understand
the language well.  I do not understand why one cannot declare an array within
a record -- one must declare an array type, then use the type within a record.
Yes, I know it is good practice to declare types, but if so why does Ada allow
array declarations (without type) at all?

{Ada,C} can be mastered, and is a useful tool.  {Ada,C} has problem areas, but
is not unacceptable as a programming tool.  The crucial factor is not the
choice of language, but the education of the human who uses the language.
The difference between the best and the average is so large that surely
there is more room for improvment in education than language design.

----
jnixon@atl.ge.com                    ...steinmetz!atl.decnet!jnxion

Re: Invalid analogy

[Tony Sanders]

In article <8222@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>   Notice: "similar flow-of-control constructs".  Both the case and 
>   the if statements execute different sections of code depending on
>   the value of a controlling expression.  A loop is a flow-of-control
>   construct, but not one which is similar to the if or case constructs,
>   which are so closely related that one is a special case of the other. 
Give me a break! (sorry, couldn't resist :-)

I make my living programming in C so I fail to see how evil and
corrupting the C programming language is.  If you make a living
programming in ADA that is just fine.  Someday, I might use ADA if I
think it is the best language for the project I'm working on at that
time.

BUT!
Please don't go around slamming some other language based on the fact
that you think that your language of choice is the ONLY programming
language that anyone should use, and then proceed to conclude that
(all/some) C programmers can't possibly write good code because their
language has to have a break statement at the end of a case.  Take it
to alt.religion.computers (where it belongs anyway) and then I'll be
happy to argue day in and day out on endlessly tiny details and nuances
of programming in each of the respective languages (see my followup line).

Simply put: ADA is not the end all of programming languages and neither
is C, both have advantages and disadvantages.  Learn them and they will
serve you well.

-- sanders                The 11th commandment: "Thou shalt use lint"
For every message of the day, a new improved message will arise to overcome it.
Reply-To:  cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders

Re: problems/risks due to programming language, stories requested

[Jeff Dalton]

In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
 >machismo is thus huffed and puffed up (another of my personal opinions is 
 >that the per capita arrogance of C programmers far outweighs the per 
 >capita arrogance of any other language-aficionado group).

Except for Pascal programmers.  Even Wirth has moved on by now.

Re: problems/risks due to programming language, stories requested

[Chuck Lins]

In article <1883@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes:
>In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
> >machismo is thus huffed and puffed up (another of my personal opinions is 
> >that the per capita arrogance of C programmers far outweighs the per 
> >capita arrogance of any other language-aficionado group).
>
>Except for Pascal programmers.  Even Wirth has moved on by now.

                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Yup. Even beyond Modula-2 to Oberon. And several colleagues at ETHZ have
enhance Oberon with object-oriented extensions.

-- 
Chuck Lins               | "Exit left to funway."
Apple Computer, Inc.     | Internet: lins@apple.com
20525 Mariani Avenue     | AppleLink: LINS
Mail Stop 41-K           | 
Cupertino, CA 95014      | "Self-proclaimed Object Oberon Evangelist"
The intersection of Apple's ideas and my ideas yields the empty set.

Re: problems/risks due to programming language, stories requested

[David F. Carlson]

In article <6960@internal.Apple.COM>, chewy@apple.com (Paul Snively) writes:
> 
> 
> 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.

What break does is *very* well defined and is no more prone to misinterpretation
that any other non-linear control flow statement in any other PL.

From K&R2 p 244:

	A9.5: iteration statement is (for, while, do)...

	A break statement may appear only in an iteration statement or a switch 
	statement; control passes to the statement following the terminated
	statement.

A multi-case switch is very handy in many situations to reduce identical
treatments for similar cases.  That you ask the question of the usefulness
of break-per-case/multiple-cases implies that you haven't sufficient experience
with the construct to judge its merits/weaknesses.

Dijkstra notes that no programming language can prevent a poor programmer from
creating bad programs.

-- 
David F. Carlson, Micropen, Inc.
micropen!dave@ee.rochester.edu

"The faster I go, the behinder I get." --Lewis Carroll

Re: problems/risks due to programming language, stories requested

[William Thomas Wolfe, 2847]

From dave@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.  

   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.  


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

Re: problems/risks due to programming language, stories requested

[jbaker]

In article <8218@hubcap.clemson.edu> Bill Wolf writes:
>From dave@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@gmuvax.gmu.edu

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

Re: problems/risks due to programming language, stories requested

[Lou Steinberg]

In article <2596@gmu90x.gmu.edu> jbaker@gmu90x.gmu.edu (jbaker) writes:

> In article <8218@hubcap.clemson.edu> Bill Wolf writes:
> >From dave@micropen (David F. Carlson):
> >> 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.

ARGHHH!!  That is what subroutines (and macros) are for - to handle
common code.  And if your language makes them too expensive, either in
terms of run time or in terms of programmer effort, then THAT is an
even worse problem with the language than the problems with break.
-- 
					Lou Steinberg

uucp:   {pretty much any major site}!rutgers!aramis.rutgers.edu!lou 
arpa:   lou@cs.rutgers.edu

Re: problems/risks due to programming language, stories requested

[Gianfranco Ciardo]

In article <Mar.8.10.19.49.1990.3812@atanasoff.rutgers.edu> lou@atanasoff.rutgers.edu (Lou Steinberg) writes:
> > >> A multi-case switch is very handy in many situations to reduce identical
> > >> treatments for similar cases.  
> ARGHHH!!  That is what subroutines (and macros) are for - to handle
> common code.  And if your language makes them too expensive, either in
> terms of run time or in terms of programmer effort, then THAT is an
> even worse problem with the language than the problems with break.

I think you miss completely the point.
Using subroutines is not going to help you make the code shorter, more compact,
or less repetitious (which is not) in a case like this:

          switch (what_to_do) {
                    case FIVE_THINGS:
                            <statementA>;
                    case FOUR_THINGS:
                            <statementB>;
                    case THREE_THINGS:
                            <statementC>;
                    case TWO_THINGS:
                            <statementD>;
                    case ONE_THING:
                            <statementE>;
                    case NOTHING:
                            break;
          }

Re: problems/risks due to programming language, stories requested

[David Kassover]

In article <672@software.software.org> ciardo@software.org (Gianfranco Ciardo) writes:
...
>
>I think you miss completely the point.
>Using subroutines is not going to help you make the code shorter, more compact,
>or less repetitious (which is not) in a case like this:
>
>          switch (what_to_do) {
>                    case FIVE_THINGS:
>                            <statementA>;
>                    case FOUR_THINGS:
>                            <statementB>;
>                    case THREE_THINGS:
>                            <statementC>;
>                    case TWO_THINGS:
>                            <statementD>;
>                    case ONE_THING:
>                            <statementE>;
>                    case NOTHING:
>                            break;
>          }

No, but without fall through, you would write such a thing upside
down.  Or do something else.
 
A couple of weeks ago I mentioned a (please bear with me) Fortran
preprocessor called FLEX, which provided 4 kinds of case
statement, two with fall through, two without.
 
One instance:  A particular programmer, whom I have worked with
for about 10 years, rarely, if ever, used the FLEX
cases-with-fallthrough.
 
Now that he has learned C (and not recently, bTW), it seems like
he goes out of his way to *USE* fall-through.


I wonder why it is so difficult for language designers to provide
more than one way to do things?

Re: problems/risks due to programming language, stories requested

[Erann Gat]

In article <672@software.software.org>, ciardo@software.org (Gianfranco Ciardo) writes:
> Using subroutines is not going to help you make the code shorter, more compact,
> or less repetitious (which is not) in a case like this:
> 
>           switch (what_to_do) {
>                     case FIVE_THINGS:
>                             <statementA>;
>                     case FOUR_THINGS:
>                             <statementB>;
			[etc.]
>                     case ONE_THING:
>                             <statementE>;
>                     case NOTHING:
>                             break;
>           }

No, but writing the code like this will:

	if (what_to_do >= ONE_THING) <statementE>;
	if (what_to_do >= TWO_THINGS) <statementD>;
	if (what_to_do >= THREE_THINGS) <statementC>;
	if (what_to_do >= TWO_THINGS) <statementB>;
	if (what_to_do >= ONE_THING) <statementA>;

If you wish to quibble over my use of inequalities, replace them with
a disjunction of equalities.

Erann Gat                  gat@robotics.jpl.nasa.gov

Re: problems/risks due to programming language, stories requested

[Andrew P. Mullhaupt]

> or less repetitious (which is not) in a case like this:
> 
>           switch (what_to_do) {
>                     case FIVE_THINGS:
...

This stuff doesn't belong in comp.lang.pascal. It goes in comp.lang.c,
right(?). The fistfight over bill wolfe's complaints about C should
stay in comp.lang.c. If anyone wants to complain about Pascal, then
put it in here. 

BTW - fall through and the 'double duty' break keyword are
definitely examples of C flaws.  If you must, flame me, but in 
comp.lang.c, (OK?)

Later,
Andrew Mullhaupt

Re: problems/risks due to programming language, stories requested

[Peter da Silva]

> This stuff doesn't belong in comp.lang.pascal. It goes in comp.lang.c,
> right(?).

No, it doesn't belong in comp.lang.c either. Language lawyers should hold
their court in comp.lang.misc or alt.religion.computers. this thread may have
some slight relevence to comp.software-eng. It doesn't belong in any of
comp.lang.{c,ada}... and even less in comp.lang.{lisp,modula2,pascal}.
-- 
 _--_|\  `-_-' Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \  'U`
\_.--._/
      v

Re: problems/risks due to programming language, stories requested

[Jeff Clark]

In article <775@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes:

   This stuff doesn't belong in comp.lang.pascal. It goes in comp.lang.c,

Actually, I don't think it belongs in any of these groups.   This "discussion"
seems to have no end and no reasonable resolution since the antagonists
arguments are based on personal opinions, preferences, and emotions.  I've not
seen anyone quote studies of the influence of "human factors" in programming
language design nor has any one proposed such a study as a useful outcome of
this recent flame war (although I must admit I'm wearing out the 'n' key on my
workstation).

comp.lang.religious-wars anyone?

Jeff Clark	Honeywell Systems and Research Center	Minneapolis, MN
inet: jclark@src.honeywell.com		tel: 612-782-7347
uucp: jclark@srcsip.UUCP		fax: 612-782-7438
DISCLAIMER: If you think I speak for my employer, you need serious help ...

Proposal comp.lang.jihad (was Re: problems/risks due to blah etc.)

[What`s in a name?]

In article <775@s5.Morgan.COM> amull@Morgan.COM (Andrew P. Mullhaupt) writes:
>This stuff doesn't belong in comp.lang.pascal. It goes in comp.lang.c,
>right(?). The fistfight over bill wolfe's complaints about C should
>stay in comp.lang.c. If anyone wants to complain about Pascal, then

No.  People who want to discuss C can do so in comp.lang.c.  The fistfight
over Bill Wolfe, and his comments can go into comp.lang.jihad.  I imagine
that these other groups would like to see a number of threads piped into
said new newsgroup as well...  Anybody want to take this one seriously?  

							--mike


-- 
Mic3hael Sullivan,                    Society for the Incurably Pompous
		     		-*-*-*-*- 
I'd hate to write a requiem and then not die.  -- Jean Cardinale

Re: problems/risks due to programming language, stories requested

[Tony Sanders]

In article <8218@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
>   So is a multi-alternative case, as provided by Ada:
How do you do this in ADA?

    switch(n) {
      case 0:
	count++;
      case 1:
	ocount++;
      case 2:
	printf("%d %d\n",count,ocount);
	break;
      default:
	printf("unknown n\n");
	break;
    }

See how I left out the breaks on purpose.

In ADA you wouldn't be able to do this without duplicating either the
case-expression (they aren't always simple numbers) or the statements.

-- sanders                The 11th commandment: "Thou shalt use lint"
For every message of the day, a new improved message will arise to overcome it.
Reply-To:  cs.utexas.edu!ibmaus!auschs!sanders.austin.ibm.com!sanders

Re: problems/risks due to programming language, stories requested

[Erland Sommarskog]

I tried thrice mailing this guy, including the path(!) he gave
in his signature. Couldn't IBM afford to be better connected?

Tony Sanders (sanders@sanders.austin.ibm.com) writes:
>How do you do this in ADA?
>
>    switch(n) {
>      case 0:
>	count++;
>      case 1:
>	ocount++;
>      case 2:
>	printf("%d %d\n",count,ocount);
>	break;
>      default:
>	printf("unknown n\n");
>	break;
>    }
>
>See how I left out the breaks on purpose.

Cross you heart, how often in practical programming do you
write such code?  And how often compared to normal switch
statements where an easily elided break would introduce
a simple bug? It might be that I never program in C, but I 
have never felt the need for a fall-through. Also, it seem more
frequent that I first want to execute some common code and
then split the cases further. In this case C's fall-throughs
help you none.

In Ada (please note, it's not all-capital) I would probably
have written the above as:

    IF N = 0 THEN
       Count := Count + 1;
    END IF;
    IF N IN 0..1 THEN
       OCount := OCount + 1;
    END IF;
    IF N IN 0..2 THEN
       Put(Count, 10);
       Put(OCount, 10);
       New_line;
    ELSE
       Put_line("Unknown.");
    END IF;

With a one-line statement for N = 2, I might have chosen to
repeat some lines of code, if the CASE statement better had
illustrated the problem. (And I would probably have made the
same arrangements in C.)
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se

Ada vs C, objectivity requested

[Lucio de Re]

In article <1771@awdprime.UUCP>, sanders@sanders.austin.ibm.com (Tony Sanders) writes:
> In article <8218@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
> >   So is a multi-alternative case, as provided by Ada:
> How do you do this in ADA?
>  
> ... silly code omitted ...
>  
> See how I left out the breaks on purpose.
>  
> In ADA you wouldn't be able to do this without duplicating either the
> case-expression (they aren't always simple numbers) or the statements.
>  
I don't think that's a serious drawback, unless you have a very
limited amount of memory. I like the facility that as you point out
does not exist in ADA, but I have got around the same lack in Pascal
and Modula 2 without any great identity crisis. And I have forgotten
the break on occasion, but I have learnt to spot the error quite
quickly, even though it is becoming more and more scarce in my code
(I generally enter all the case clauses, then separate them with
break's when using VI; in BRIEF, I would modify the macros to do this
for me).

It really is silly to knock a language on the basis of certain
constructs. Good programmers will use ADA or C successfully and bad
programmers will screw up in ADA or in C. We are not all or always
good programmers and we need to be alert to different possible
failings in the two languages. Can Bill Wolfe vouch for ADA having
no failings?

And, as justification for my satisfaction with C not putting too
many checks in my programming path, I have the following similitude:

I normally ride a motorcycle at speeds in excess both of speed
limits and of traffic speeds. I have to be very alert to survive, as
automobile drivers seem utterly oblivious of my presence. If I
travel more slowly, my attention span decreases and I become less
alert. Also, not being insured, I find I am more conscious of my
vulnerability than I was when I was insured.

Similarly, in C I try very hard to avoid its pitfalls. I follow this
thread because of the pitfalls that have been brought up (none that
I wasn't aware of, yet) and I regret my lack of ADA knowledge, at
least to some degree. In Modula 2 I too often let the compiler pick
up my distractions, which means that semantic errors are more likely
to have crept in. Is ADA similarly soporific; if so give me C, and
programmers under my supervision will program in Modula 2 because I
know the quality of the code I produce and I also know the type of
clever (read illegible, often wrong or at the very least incapable
of coping with special cases) code that less disciplined programmers
can produce in C. But it is an issue of survival. Bad C programmers
will eventually hang themselves, the same way that bad motorcycling
would have killed or crippled me long ago (and has killed and
crippled others) had I indulged in it. C requires self-discipline
where Modula 2 and ADA force discipline on you. The result is that C
programmers have more freedom, the price for which is one of greater
alertness or the possibility that the compiler won't pick up what
might be a simple mistake, while ADA and Modula 2 programmers have
to be devious to do what they may have to do that the language
inhibits.

And further, ADA suffers from a very bad disease: committeetis. By
the time a committee completes a definition, it cannot possibly have
included the latest developments in language design. Worse, once the
definition is finalised, implementation stretches further and the
language is (in at least some facets) obsolete by the time the
implementation is complete. To quote an example from the other side,
the ANSI standard for C has been superceded, prior to publication by
the availability of C++ compilers. Ironic? The standard has its
place, but it would be sad to stifle further development in C++ by
promulgating a standard that freezes it at this stage, for example.
We are learning so much, it is impossible to encompass all GOOD
language features in any one committee generated standard (thank
goodness!).

Take another point. The "0b" prefix Walter Bright added to provide
binary number representation is an obvious extension to C. The ANSI
committee did not consider it, nor did Stroustrup. Well, I like it
and I use it, and I would like it incorporated into the ANSI
standard. Certainly I would hate to lose it because some committee
states that its implementation invalidates my compiler's compliance
with the standard.

----------------------------------------------------------------------
I used to design nuclear reactors and you should see the code that
engineers and scientists come up with. Yuuuck! Spaghetti everywhere.
-------------------------------------------------- (Kenneth L Moore) -
Lucio de Re                        ...uunet!ddsw1!olsa99!proxima!lucio
-------------------------------------------------------- lucio@proxima
                Disclaimer: He must have been joking!

Re: Ada vs C, objectivity requested

[Karl Heuer]

This subthread is C-specific.  I am redirecting followups to comp.lang.c.
\f
In article <567@proxima.UUCP> lucio@proxima.UUCP (Lucio de Re) writes:
>Take another point. The "0b" prefix Walter Bright added to provide
>binary number representation is an obvious extension to C. The ANSI
>committee did not consider it...

It *was* considered, but rejected.  I suspect the response was "Insufficient
utility; Does not address a major deficiency; No established current practice"
or something like that.

>Well, I like it and I use it, and I would like it incorporated into the ANSI
>standard.

No problem.  Campaign to have it added to gcc; hint to your other vendors that
you like the feature.  If it's current practice when the next time around, it
has a much better chance of making it into C-2000.

>Certainly I would hate to lose it because some committee states that its
>implementation invalidates my compiler's compliance with the standard.

The feature doesn't break any existing code.  At worst, it requires a warning
diagnostic when the compiler is run in strictly pedantic ANSI mode.  The fact
that ANSI doesn't support it is not an excuse for not providing it.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint

Re: problems/risks due to programming language, stories requested

[jaws]

Mr Wolf:

C allows you to combine cases that have portions of similiar code
but may have extra lead in code for a specific case:

	switch var:
	case A:
		/* do stuff only case A needs */

	case B:
		/* do stuff case A and case B need done */
		.
		.
		break;

	/* rest of switch */
	

this construct in impossible to do cleanly in almost every language I have
ever seem, especially ADA.

This kind flexiability is what makes C so powerfull, and dangerous. 
You have know what you are doing to do it.


[ Jeff Wilson :: jaws@chibacity.austin.ibm.com                                ]
[ Consultant from Pencom, Inc. at Human Factors, AWD, IBM Austin.             ]
[My comments are wholly my own and as such take them for what they are worth. ]

Re: problems/risks due to programming language, stories requested

[Jim Giles]

From article <1004@micropen>, by dave@micropen (David F. Carlson):
> [... explicit breaks in the C switch construct ...]
> Dijkstra notes that no programming language can prevent a poor programmer from
> creating bad programs.

He also notes that the choice of programming language can have a strong
effect on the quality of the resulting code.  (His indictment of PL/I
as being similar to flying a widebodied jet with all the windows taped
over and no labels on the thousands of controls was quite apropos.)
This effect of the language choice is mainly psychological - and it
CAN be overcome (which is the main thrust of many of Dijkstra's works).
But, be honest, how many programmers do you know who _really_ construct
their programs abstractly _before_ even selecting their implementation
language?  This is the proper way (a' la Dijkstra) to make sure the
you aren't negatively impacted by the language - you select the proper
language for the job at hand - you don't mangle the job to fit the
language.

Dijkstra's statement, while true, should not be used to excuse poorly
designed language features (as you are trying to do).  A better design
for C would have been _not_ to require breaks after each case and to
provide some other syntax for the representation of multiple choices
on the same case.  It's easy to see these kinds of design errors
in retrospect (C _is_ nearly 20 years old you know).

J. Giles

Re: problems/risks due to programming language, stories requested

[Vincent Manis]

I might note that B's syntax, and hence C's syntax, was a definite
*dis*improvement [sic] over that of its predecessor, BCPL. I would in
fact post an article saying exactly that, except for the fact that this
entire thread most certainly belongs somewhere, but not in
comp.lang.scheme.  Would you please edit the Newsgroups: line in further
articles on this subject?

--
\    Vincent Manis <manis@cs.ubc.ca>      "There is no law that vulgarity and
 \   Department of Computer Science      literary excellence cannot coexist."
 /\  University of British Columbia                        -- A. Trevor Hodge
/  \ Vancouver, BC, Canada V6T 1W5 (604) 228-2394

Re: problems/risks due to programming language

[Karl Heuer]

In article <1004@micropen> dave@micropen (David F. Carlson) writes:
>What break does is *very* well defined and is no more prone to
>misinterpretation that any other non-linear control flow statement ...

Yes, it's well defined, but what it's defined to do is bad.

For a formal treatment of the above statement, I refer you to my article
<16039@haddock.ima.isc.com>, posted to comp.lang.misc (also .c and .ada) with
this same title.  I haven't seen any rebuttals yet.

>A multi-case switch is very handy in many situations ...

Yeah.  I wish C had this feature, instead of simulating it with fallthrough.

>That you ask the question of the usefulness of break-per-case/multiple-cases
>implies that you haven't sufficient experience with the construct to judge
>its merits/weaknesses.

I don't know about the person you were addressing, but I think I've had
sufficient experience with it.  I certainly question its usefulness in
comparison to something reasonable, like the language I described in my other
article.

In fact, even if you insist that the comparison must be between C and
plain-C-without-break-switch, I think I'd still go for the latter.  I believe
the benefit of not requiring an overloaded keyword to do a break-switch
exceeds the cost of having to use a goto to merge related cases.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint

Re: problems/risks due to programming language, stories requested

[William J. Bouma]

In article <6960@internal.Apple.COM> chewy@apple.com (Paul Snively) writes:
>We all know C programmers whose 
>machismo is thus huffed and puffed up (another of my personal opinions is 
>that the per capita arrogance of C programmers far outweighs the per 
>capita arrogance of any other language-aficionado group).


   Oh, really! I can tell you have never met any FORTH programmers.

 
>Well, I hate to say it, but it's extremely unlikely that such an error 
>would have been made in Pascal, since Pascal doesn't require you to 
>explicitly break from case...of constructs.


   Well isn't that special! The way I see it, C gives you the flexibility
   to not break if you don't want to, where PASCAL restricts you to break.


>Before the flames start,

   Too late!

> let me just add: no, I don't necessarily prefer Pascal over C for all tasks.


   The only place I can see to prefer PASCAL over C is a beginner programming
   class. Isn't PASCAL usually thrown out along with the diapers?
   
-- 
Bill <bouma@cs.purdue.edu>  |  And don't forget my dog... "Astronomy" -- BOC

Re: problems/risks due to programming language, stories requested

[Lindsay Groves]

In article <1004@micropen>, dave@micropen (David F. Carlson) writes:
> What break does is *very* well defined and is no more prone to
misinterpretation
> that any other non-linear control flow statement in any other PL.

A number of people in this discussion (which I haven't reached the end of yet!)
have said things like this, and appear to be suggesting that because something
is well defined there is no excuse for anyone misusing it.  I disagree
with that
and also with the second part of this statement.  There are languages in which
any kind of exit has to explicitly name the construct to be exitted -- so there
is no possiblity of consfusion about which construct the exit/break/etc.
applies
to.

> A multi-case switch is very handy in many situations to reduce identical
> treatments for similar cases.  That you ask the question of the usefulness
> of break-per-case/multiple-cases implies that you haven't sufficient
experience
> with the construct to judge its merits/weaknesses.
> 
> Dijkstra notes that no programming language can prevent a poor
programmer from
> creating bad programs.

So why aren't we all still using FORTRAN (or some older dialect)?  Why did we
all think that unlabelled CASE statements (as in Algol-W and Burroughs Algol)
were a big improvement over computed GOTOs in FORTRAN (which is basically what
the switch in C is), or that the labelled CASE statement (as in Pascal) was
a big improvement over that?  Maybe the whole of the last 30 years of work in
programming language design has been a dream!!!

Lindsay Groves

Re: problems/risks due to programming language

[Scott MacHaffie]

In article <8126@hubcap.clemson.edu% billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes:
%From machaffi@fred.cs.washington.edu (Scott MacHaffie):
%% No, it is necessary to use a statement to indicate that the current case
%% statement is finished...like an "end case" or the next "when =% " in ADA.
%
%   Such a statement already exists: either the next "case Value:", or 
%   the } which ends the switch.  Why is it necessary to use a "break"?

example:
	switch (x) { /* x is a character, for example */
		case '0': case '1': ... case '9':
			print_digit(x);
			break;
		case 'a': ... case 'z':
			print_lowercase(x);
			break;
	}
The semantics of a C switch/case statement are different than the semantics
of an ada case/when.

%   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. 

Good programmers understand the language they are using -- good programmers
are literate. No language can eliminate errors. Good software engineering
practices should be used to (try to) catch language-specific errors.

%%%   This is certainly true; Brooks and others have noted that the good
%%%   software engineering practices which are routinely introduced in
%%%   conjunction with the Ada language are responsible for more of the 
%%%   resulting improvements than the fact that the Ada language was
%% 
%% Well, these practices are certainly NOT being introduced in the 
%% universities (at least not here).
%
%   In that case, I strongly suggest that you immediately bring 
%   this fact to the attention of the software engineering faculty 
%   at washington.edu.  At other universities (e.g., Clemson), Ada
%   *is* introduced in conjunction with software engineering.

Software engineering faculty?  I wish. None of the undergraduate classes
here touch software engineering, and I think at most one of the graduate
classes does. Anyone who wants to be a software engineer here has to
pick it up from other sources.

			Scott MacHaffie

Re: problems/risks due to programming language

[B. S. Oplinger]

Consider the following (slightly modified from the example by Scott MacHaffie):

example:
        switch (x) { /* x is a character, for example */
                case '0': 
                        number_of_groups ++;
                case '1': ... case '9':
                        print_digit(x);
                        break;
                case 'a': ... case 'z':
                        print_lowercase(x);
                        break;
        }


In my example, 0 is just like any other number except that it signals
the start of a new group, hence the increment on the number-of-groups
counter.  This is just the problem with the syntax of the C case
(switch) statement. It is designed so that a case may do some work and
then 'share' the work of the following case statement. I will submit
that this general attitude is found throughout C. Ada, although not a
perfect language, is almost always presented with some discussion on
software-engineering. I feel that this help promote good work habits. 

On LINT, I would never program without it (in C). There is no excuse
for today's language running on todays machines (hell, even the PC)
that LINT checking cannot be done during a compile. I believe that it
should also be an option that must be turned off, not on.

various random thoughts from:

brian
oplinger@crd.ge.com

<#include standard.disclaimer>

Re: problems/risks due to programming language

[Erland Sommarskog]

Scott MacHaffie (machaffi@fred.cs.washington.edu.cs.washington.edu) writes:
)Bill Wolfe (billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu) writes:
))   the NEXT case.  In other words, C requires the programmer to use a
))   dangerous construct on a routine basis.
)
)(the dangerous construct is the "break" statement)
)But if "break" were renamed "end case" then there wouldn't be any problem?
)
))   code associated with the else part.  Thus, we have an inconsistency
))   in C's design: with one flow-of-control construct (the switch), it is
))   necessary to use a dangerous GOTO to achieve normal processing, whereas
)
)No, it is necessary to use a statement to indicate that the current case
)statement is finished...like an "end case" or the next "when =) " in ADA.

I don't speak C, so I might have missunderstood something, but I'm
under the impression that you may exclude the "break" statement
achieving the effect that you execute the code for the next case too.
Sometimes possibly a nifty feature, but it seems to me that is a good
source of errors. Whether it's called "break" or "end case" has no
importance. You may inadvertantly forget it in both cases.

)I don't use LINT. I use compilers that check certain things I want checked,
)like "no prototypes in scope".  LINT does not catch the kinds of mistakes
)that I make.  How many ADA programmers do you know of use LINT?

Ada programmers don't use lint, they don't have to.

From another article by Scott MacHaffie:
)Good programmers understand the language they are using -- good programmers
)are literate. No language can eliminate errors. Good software engineering
)practices should be used to (try to) catch language-specific errors.

And good languages should have as few unnecessary traps as possible
to help the software engineer spend his efforts on essentials.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se

Re: problems/risks due to programming language

[What`s in a name?]

In article <806@enea.se> sommar@enea.se (Erland Sommarskog) writes:
>Scott MacHaffie (machaffi@fred.cs.washington.edu.cs.washington.edu) writes:
>)Bill Wolfe (billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu) writes:
>))   the NEXT case.  In other words, C requires the programmer to use a
>))   dangerous construct on a routine basis.

>))	[stuff deleted]

>))   code associated with the else part.  Thus, we have an inconsistency
>))   in C's design: with one flow-of-control construct (the switch), it is
>))   necessary to use a dangerous GOTO to achieve normal processing, whereas
>)
>)No, it is necessary to use a statement to indicate that the current case
>)statement is finished...like an "end case" or the next "when =) " in ADA.
>
>I don't speak C, so I might have missunderstood something, but I'm
>under the impression that you may exclude the "break" statement
>achieving the effect that you execute the code for the next case too.
>Sometimes possibly a nifty feature, but it seems to me that is a good
>source of errors. Whether it's called "break" or "end case" has no
>importance. You may inadvertantly forget it in both cases.
>

Yupper.  To quote the Holy Scriptures:

"Falling through cases is a mixed blessing.  On the positive side, it allows
several cases to be attached to a single action... But it also implies that
normally each case must end with a break to prevent falling through to the
next.  Falling through from one case to another is not robust, being prone
to disintegration when the program is modified.  With the exception of
multiple labels for a single computation, fall-throughs should be used
sparingly and commented.
	"As a matter of good form, put a break after the last case even
thought it is logically unnecessary.  Some day when another case gets added
at the end, this bit of defensive programming will save you." (K&R p.59)

So, yes I'll agree this is a slight flaw in the case statement, but I'm not
sure I buy all this garbage about "break" being a "dangerous construct."

There has been a war on GOTO constructs for some time and while it certainly
began with reason (remember BASIC without labels???:-)), it gets to the
point where efficiency is not saved.  One really must go to great lengths to
program anything significant without some sort of flow control, which at the
machine level breaks down into conditional or unconditional jumping... (Yes,
a GOTO (EEEEEEKKKKK!!!!)).  

So, we want to be reasonable in our jumps, giving them certain well defined
conditions and having only certain types.  So we *do* indeed, for the most
part want to get rid of the monstrosity known as "GOTO label" (To say
nothing of the kind of line I could write in TRS-80 basic: 
    
     20 IF X OR 2 100 /* This jumps to line 100 if the 2 bit is set in X */
).

In fact I would argue that all GOTO like constructs should be conditional
and local.  And so they are (almost) in C.  For, while, switch, do... -- all
local, and all conditional except one:  break (Yeah, C has goto but everyone
knows never to use *that*).  But break is rather well defined in C.  It exits
from the innermost for, while, do or switch statement.  It goes to an easily
noticeable place near it in the code, unlike goto (let's go label hunting!).
Now I could argue that making the break statement conditional i.e. :

break(expression);  performs break if expression is true, nothing if false.

would be a good idea.  For one thing certain loop breaking would be easier
to write.  Admittedly the common uses in switch statements would require
three extra characters...  I don't think it's a big enough deal to be worth
changing.  Break simply isn't that dangerous.  I'm not so sure GOTO is all
that dangerous if treated with the proper respect (But then I've done
assembly programming...:-)). 

Arguments for the break statement:  Do you ever want to break out of a
while, for or do construct?  ("Oh, no!" I hear some say, "Properly written
programs *never* need do that."  My answer:  Yes, you are right and BTW,
every reasonable language is Turing Equivalent -- go program on a turing
machine.) The only option without some kind of break statement, is to use
flag variables and a couple of extra conditionals (Quoth my algorithms
professor, "Flag variables are as ugly as gotos, but they can't be helped in
Standard Pascal...").  

Thing is, lot's of things are pretty dangerous in programming languages but
these things can be very useful.  Noone in their right mind can claim that
pointer manipulation is any less dangerous than a flat out goto label
statement (IMNSHO, it's tremendously more dangerous), but would any
reasonable programmer trade it for the world?  There is simply too much that
becomes easy and elegant when you use pointers into real memory instead of
having to create your own integer index pointers into arrays simulating
memory in order to implement, say, a tree.  We did this in my algorithms
class, in order to learn about how pointers are implemented.  It's not that
hard, just painful and complicated.  I'll take pointers any day of the
week.  

I'm saying that we need not be quite so anal-retentive about the constructs
we allow in programming languages.  Admittedly, C is not for the faint of
heart, and I'll be surprised if it catches on in the big business world.
There is too much need for programming and not enough programmers who can
handle a C environment.  That's ok by me -- I'm really not interested in
that sort of dp anyway (although the poor saps ought to get something better
than C*BOL to use).  But the one thing that makes C more dangerous, more hairy,
more able to strike fear into the heart of the novice programmer than even
the demonic teenage Mike S. with his TRS-80 model III spaghetti basic
interpreter using Machine Language subroutines left and right, is C's use of
pointers and operators.  Not the silly break statement or some small
weakness in the switch.  

C pointers and operators, while hairy, are extremely elegant.  This is why
so many people like to program in C.  But admit it, they are not trivial to
understand.  So my main point is this:  

Anyone who has any business programming in C, should be able to handle a
switch statement where cases fall through.  

And it's true, every C programmer gets steeped in the heritage of the
switch.  Why the third commandment of C states quite clearly:

"Thou shalt put a break statement at the end of each case in a switch, even
unto the last in which it is not logically necessary."

So what's the problem?  If you feel so strongly about a switch statement
than you are obviously of a different school than C'ers.  

There are two main schools of looking at language implementation.  One,
typified by Standard Pascal, says that the programmer probably doesn't know
what s/he is doing and that a language should not let him/her do anything
even slightly out of the ordinary.  The second, typified by C, says that the
programmer knows or should know what s/he is doing and so "I'll just do what
s/he tells me as long as I understand what s/he is saying."  If you are a
type I programmer, using C must feel like walking a tightrope between the
towers of the world trade center.  If you are a type II programmer, using SP
is like trying to answer the four-year-old who has learned how to ask, "Why?"

The best languages are obviously not going to go whole hog in either
direction, but in general you should use what you feel comfortable with.  I
like C, You like Ada, so use what you like.  I think K&R made a reasonable
choice with break.  I like being able to fall through a switch, even if I
have to take a little care with it.  Do you think I type *anything* in C
without taking a certain amount of care?  

							--mike


-- 
Mic3hael Sullivan,                    Society for the Incurably Pompous
		     		-*-*-*-*- 
"In the usual way":  That's a phrase that mathematicians use to let you know
they're smarter than you are.				--Norman Stein

Re: problems/risks due to programming language

[Karl Heuer]

I'm redirecting followups to comp.lang.misc.

In article <5479@ur-cc.UUCP> Michael Sullivan writes:
>[A lot of strawman arguments]

I don't think anybody is seriously arguing the position that you seem to be
attacking.  I also don't know how closely my position matches that of the
other participants in this debate, but I'll state mine as a series of claims
for you to agree with or rebut as you like.

It's meaningless to say "the `break' keyword is {good,bad}"; you have to have
an alternative to compare against.  I will use the notation `C with feature X'
to mean `a hypothetical language which is a lot like C but which has feature
X'; then we can make statements like `C with X would be a better tool than C'.

I am not arguing that C should be changed in this regard (except by adding
warning messages where appropriate).  Thus, the existence of a large body of
code written in C-as-it-is-today is not a factor in such comparisons.

We need to distinguish between keywords and the operations they denote.  It
turns out to be useful to distinguish two operations, which I will call
`break-switch' and `break-loop', both of which are denoted by the keyword
`break' (depending on context).  I will use the term `fall-through' to denote
the operation of flowing from the end of one case into the beginning of the
next one; this operation is denoted in C by the absence of a `break' keyword
in reachable flow at the end of a case block.

Claim 0.  Much use of fall-through in C is simply attaching several cases to a
single action.  (In fact, this is the `positive side' you quoted from the Holy
Scriptures.)  Some other languages achieve this by allowing multiple values to
be associated with a single case label, instead.  Thus, C with multiple valued
cases would not need fall-through nearly as often.

Claim 1.  A break-switch is rarely needed at any point other than at the end
of a case block.  At the end of a case block, break-switch is needed much more
often than fall-through.

Claim 2.  As a general principle, if there is a default action it should be
the most common of the alternatives.  This tends to minimize certain kinds of
user errors.

Definitions.  Let `CX' be the language C with multiple valued cases, with
automatic break-switch at the end of each case block, and with the `break'
keyword denoting only the break-loop operation.  `CX with jumpcase' is CX
with an explicit keyword to denote the fall-through operations (overriding the
default behavior of an automatic break-switch).

Claim 3.  CX with jumpcase would be better than C.

Claim 4.  CX itself would be better than CX with jumpcase (and hence better
than C); the extra keyword doesn't buy you enough to be worth adding, and it
would destroy the commutativity of case blocks, which is a useful property of
CX.

Claim 5.  Because C, not CX, is what we actually have, and because of what I
said in Claim 1, a useful feature of C compilers and/or checkers (lint) is the
ability to produce a warning if (a) a `break' keyword denoting a break-switch
operation appears anywhere other than at the end of a case block, or (b) a
(reachable) fall-through operation occurs at the end of a case block.

Claim 6.  In the case of lint, at least, such warnings should be enabled by
default.  There should be lintpragmas (e.g. /*SWITCH*/, /*FALLTHROUGH*/) that
can selectively disable them.

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint

Re: problems/risks due to programming language

[Erland Sommarskog]

Michael Sullivan (misu_ss@uhura.cc.rochester.edu) writes:
>"Thou shalt put a break statement at the end of each case in a switch, even
>unto the last in which it is not logically necessary."
>
>So what's the problem?

The problem? Such rules such be enforced by the compiler, not the
programmer. The more rules you into a language which the programmer
is to obey without the compiler to verify, the more likely it is
that casual errors slip in. And the compiler checks for me, the more
I can concentrate on the essentials; trying to solve the real-world
problem at hand.
-- 
Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se