Paul, All valid points, but sadly Ada is not available for the micro-controllers I'm using in the Mark II glider. And I would have to write all my libraries from scratch, rather than working on a base of other's proven code. There is also the issue that I would need to learn a new language, which I admit I'm somewhat lazy about. As things turned out, the only onboard software bug that caused any problem was a single case of forgetting to use fabs(float) in one conditional line. Microsoft's stuff is a different story, however. But the ground software is non-critical. Sincerely, Art Vanden Berg At 05:32 AM 26/01/2005, you wrote: >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