TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Paul Colin Gloster <[log in to unmask]>
Reply To:
Date:
Wed, 26 Jan 2005 14:32:09 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (77 lines)
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

ATOM RSS1 RSS2