Paul,

(Thanx very much for this brief but quite helpful e-main re Ada
contemporary, safety critical features..)

     Jon

>From: Paul Colin Gloster <[log in to unmask]>
>Reply-To: [log in to unmask]
>To: [log in to unmask]
>Subject: Re: High Altitude Glider Project & Programming Language
>Date: Wed, 26 Jan 2005 14:32:09 +0100
>
>Laurent GUERBY quoted from http://members.shaw.ca/sonde/software.htm on
>the Team Ada email list:
>
>"[...]
>What Language / Platform?
>
>[..]
>
>[..] But Ada's structure and design-for-reliability approach is
>burdened by poor support on "civilian" platforms, and in particular a
>very large instruction set that, in the view of many experts in the
>field, hinders its in-practice suitability for reliable systems, no
>matter what its reputation is. [..]"
>
>Uhh, how about the proper affordable x86 Ada compilers which do not even
>need an 80286; which are still available on the market; and which are not
>the GNAT DJGPP trash?
>
>"What I settled on was using an old language, C, in a rigorous way. [..]
>
>[..] The book Safer C - Developing Software for
>High-Integrity and Safety-Critical Systems, has also been a great help,
>as have numerous websites (most of which I've since lost track of), on
>developing good programming practices.
>[...]"
>
>Losing your rationale does not seem like a good practice. Can even 60% of
>the problems Les Hatton points out in his book even occur in Ada? I am
>reminded of a colleague some of whose plans I had to review a few months
>ago, who acknowledged that C is dangerous but said that it can be (and
>worse, should be) used so long as special care is taken to write safe C.
>
>A quotation from that document written last year which purported to be
>following safe C coding:
>
>"No Magic Numbers
>[..]
>One of the many useful features of the C language is the #define construct
>which allows the definition of a value, which can be used anywhere in the
>code, for example:
>#define FOO 13
>// lots of code
>jibble = FOO * myVar;
>bar = quux/FOO;
>This allows for a simple alteration to the first line, to alter the value
>through out the program."
>
>From page 20 of Brian W. Kernighan's and Rob Pike's "The Practice of
>Programming": "DEFINE NUMBERS AS CONSTANTS, NOT MACROS. C programmers have
>traditionally used #define to manage magic number values. The C
>preprocessor is a powerful but blunt tool, however, and macros are a
>dangerous way to program because they change the lexical structure of the
>program underfoot. Let the language proper do the work." They recommend
>a couple of alternatives for constant numbers in C. Interestingly, another
>of Kernighan's books was cited by the aforementioned colleague.
>
>More noteworthy still is the contrast between expert C practitioners'
>advice conflicting with the aforementioned recommendation of #define
>CONSTANT and the second item in the same document's bibliography:
>
>"Bibliography
>F. P. Brooks (1995). "The Mythical Man Month and Other Essays on Software
>Engineering". Addison.
>Wesley Publishing Company.
>
>L. Hatton (1994). "Safer C: Developing Software in High-integrity and
>Safety-critical Systems". McGraw-
>Hill Education - Europe."
>
>Furthermore, the aforementioned colleague cited one of Steve C.
>McConnell's books on software engineering, but as Steve C. mac Chonaill
>actually defended Microsoft in an interview in "Dr. Dobb's Journal" does
>not help his credibility.
>
>Regards,
>Paul Nicolas Cóilin Gloster