Re: "Subtract C, add Ada"

[ncohen@watson.ibm.com (Norman H. Cohen)]

In article <3etund$hnr@miranda.gmrc.gecm.com>, bill@valiant (R.A.L Williams)
writes: 

|> My experience of writing software and running software projects in C
|> highlights four common low-level C errors: 
|>   1. = instead of == and vice versa
|>   2. spurious ; after for(...) or while(...)
|>   3. uninitialised pointer access
|>   4. pointer references to local variables in defunct procedures
|> The syntax of Ada removes or reduces errors like 1. and 2. but does
|> not really address 3. or 4. (admitedly, 4. is an unnatural practice in
|> Ada and would be pretty rare anyway).

No, Ada helps to eliminate all four kinds of errors.

#3: In Ada, all pointers are initialized by default to null.  An attempt
to dereference a null pointer IMMEDIATELY raises Constraint_Error, so
these errors are generally discovered during testing.  (The only way they
could fail to be discovered is if the testing failed to exercise the path
along which the dereference is reached without a prior assignment of a
nonnull value.) In C such an error could remain undiscovered even if the
tests exercise the relevant path.  The arbitrary contents of the
uninitialized pointer might happen not to generate an invalid memory
reference; or the error could occur sporadically and irreproducibly, but
manifest itself only indirectly, much later in the execution of the
program, because of some datum clobbered by assignment to the variable
"pointed to" by an uninitialized pointer.  Then the error might never be
properly attributed to the dereference of an uninitialized pointer.

#4: In Ada 83, access values point only to dynamically allocated
variables, not to declared variables, so the issue does not arise.
In Ada 95, access values can pointed to variables declared aliased, but a
pointer to a local variable of a subprogram can only belong to an access
type that is itself declared inside the subprogram, so the pointer cannot
outlive the variable to which it was pointing.

|> The really strong point about Ada, especially where large teams, or
|> inexperienced coders, are involved is that it strongly encourages
|> the separation of SPECIFICATION from IMPLEMENTATION, and provides
|> a language enforced formalisation of the mechanism. Never mind the
|> commonly expressed rationale behind this, ie. information hiding: 
|> forcing the interfaces between components to be *designed* before
|> attempting to write the implementation, and then encouraging (because
|> of the sheer hassle of not doing it) some sort of formal mechanism
|> if the interfaces have to be changed has got to be the main factor in
|> the success of a project.

I agree.  I also agree with you that it is not hard for programmers who
understand the Ada philosophy to use C in a disciplined way to simulate
Ada packages.  However, violations of the discipline are not easily
recognized or enforced.  (The discipline involves, among other things,
remembering to override the inexcusable C default that functions are
extern rather than static; and always #include'ing a header file with the
declarations of a file's external functions both in the file defining
those functions--to ensure consistency as the file is modified--and in
all files calling such functions.)

But don't underestimate the power of the stupid little errors--the ones
that occur and persist in C programs, but never occur or are eliminated
immediately in Ada programs--to slow a project down or even cause its
failure.

--
Norman H. Cohen    ncohen@watson.ibm.com