Re: problems/risks due to programming language

[sommar@enea.se (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