Re: Any research putting c above ada?

[kaz@vision.crest.nt.com (Kaz Kylheku)]

In article <2senchydgk.fsf@hpodid2.eurocontrol.fr>,
Steve Jones - JON  <jon@hpodid2.eurocontrol.fr> wrote:

>On my last project we use C and Ada, the bug count in the Ada code was
>over 1/3 that of the C code. And tracking down bugs in Ada is much easier,
>the code falls over it tells you the brief reason (eg constraint error) and
>the line at which the error was raised and the stack trace.  You can then add
>exception handlers et al to secure the system. It provides in built range
>checking and strong typing.
>
>In C assigning to an unitialised pointer will cause either a crash or
>wild behaviour and never tell you, in Ada it will crash and tell you why.

Decent C compilers will diagnose when you have used an unitialized variable
rather than crashing at run time.

>In Ada you can restrict the user from assigning between incompatible types,
>you can data hide etc etc.

This is true of C as well. Assigning between incompatible types is a constraint
violation which *requires* a diagnostic. It's all in ISO 9899:1990.

>The bug count and cost of Ada is much less than that of C, just because some
>of the bugs that occur regularly in C (int a[10]; a[10] = 4; anyone ?) cannot

I believe it, but you are not describing the actual advantages of Ada over C.

>be done in Ada.  Both Ada and C can produce correct programs but IME it is
>easier to do in Ada, the same would go for Eiffel v C++, a HLL v a MLL presents
>similar advantages to a MLL over a LLL.

I would say that the same would also go for Eiffel v. Ada. Compared to Eiffel,
Ada is still a cryptic, implementation-oriented high level assembler
like C, Pascal, Modula, et al. 

>I know C, I know Ada and various languages besides, if I was writting a quick
>check or hack I'd use C, if writting a large system I'd use Ada.  The advantage
>of Ada isn't in the debugger but in the compiler, eg
>
>C:
>typedef int cleared_flight_level;
>typedef int airspeed;
>
>airspeed a = 4;
>cleared_flight_level cfl = 5;
>
>...
>
>cfl = a;

What is your point here? The two types here are compatible. You have only
created an alias name for int. In other words, C has structural equivalence
for types (other than structs).

Why don't you see a type violation in the very declarations? 

It could easily be said that

    a = 4;

is a type violation. After all, 4 is an integer, and a is an airspeed. A
decent, safe language would require a special conversion operator to be done on
the 4 to construct an airspeed from an integer. Does Ada require that?

In C you can do this:

    typedef struct airspeed { int i } airspeed;
    typedef struct cleared_flight_level { int i } cleared_flight_level;

There you go. The two are no longer assignment compatible with each other or
with the int type. You can still assign an airspeed to an other airspeed, and
pass it in and out of functions by value. The .i operation converts
an airspeed to an int.



>...
>
>This is a silly example as why would anyone _want_ to do it.  But Ada would
>prevent you ever doing it.  It is here that the power comes in, with tools
>like generics and a proper tasking model, decent hardware access is included
>and data protection, all of these things make it harder to mess up, and easier
>to check, if the range of an enumeration in C is changed a switch statement
>will not care if the new value is not included, in Ada the compiler will fail
>the code.

Ada may have the advantage that this is required behavior. But a quality C
compiler (such as the GNU C compiler) will warn you if one or more of the
members of an enumeration are not mentioned in the switch statement. 

Where C messes up is in those types of errors that _cannot_ be diagnosed
or cannot be diagnosed easily.  Other than that, a C implementation can be
retrofitted with all kinds of diagnostics that are not required by the
language. True, this lack of a requirement is a disadvantage, but it's
not a major obstacle.

>C is popular, it is quick and dirty, but I wouldn't like to trust my life to
>it.

I wouldn't trust my life to any computer system, especially if it had ``Intel
inside''. There are too many things that can go wrong _beside_ programming
errors. There is buggy hardware. There is also correct hardware which fails to
be fault tolerant. The sheer component count in a modern computer system is
astounding, as is the small size of the individual components. Would you trust
your life to a system in which an alpha particle emission can cause
unpredictable behavior?