Re: A case where Ada defaults to unsafe?

["Nick Roberts" <nickroberts@adaos.worldonline.co.uk>]

"Stuart Palin" <stuart.palin@baesystems.com> wrote in message
news:3C3C1438.FBF10FC3@baesystems.com...

> ...
> I think the important point in Simon's message was:
>
> > > making subtle deductions about the **intent of the designer** from
> > > **details of the implementation** is a big mistake.
>
> If a designer is being 'clever' or has done something in a particular
> way for a good reason, then this should be explicitly documented
> (comments at least).
>
> It is a big mistake to **have to** deduce detailed intent by attributing
> subtle meanings to code.

I agree with this principle in a big way.

However, for a lot of Ada code (maybe not flight management code), there are
always going to be situations where the designer is not available, and the
documentation and/or comments do not cover a particular design decision in
the code. Then it is, unfortunately, necessary to make deductions about the
intent of the designer from details of the implementation.

> Relating to the current thread I think I understand where Hyman is
> coming from; but feel that ** if this is an issue ** for a particular
> system that it is not difficult to adopt 'house rule' that mandate using
> 'and then' and 'or else' (and accepting all the downside aspects).

But Hyman and I can argue against such house rules (and I do!).

> I think Hyman is mistaken to think that Ada is 'by default' a ** safe
> language **; it has features that enhance safety by preventing (or
> allowing the detection of) certain types of programming error.  Even in
> subsets like SPARK it is quite possible to write unsafe programs
> (Simon's and Nick's posts illustrate this).  Safety is a system property
> and software safety can not be assessed in total isolation from the
> system.  Quite what makes a system ** unsafe ** will depend on the
> hazards facing the system and what are and are not permitted actions.

I suspect Hyman wouldn't put Ada's safety in quite such stark terms. I think
he was trying to say that Ada's features are normally safe by default,
rather than that the language as a whole is somehow magically safe (and so
programs written in Ada will never fail).

My experience is that the biggest number, and worst kind, of 'bugs' in a
safety-critical system are introduced long before the coding stage. No kind
of coding can eliminate these bugs. [This is why the strategy of hedging
with multiple codings (based on one specification) horrifies me so much, but
that's another argument.]

> My own pet peeve in Ada is the choice of comment token;
>   A := very_long_name_B - very_long_name_C
>        + very_long_name_D -- very_long_name_E
>        - very_long_name_F;
>
> While thorough forms of testing should readily detect the 'missing'
> reference to E, it just seems silly to introduce the risk of a simple
> typo involving a commonly used mathematical symbol; especially when
> there seem to be plenty of (otherwise) unused symbols available.

Hmm. How about:

   A := B + C; \~~~@@@^^^$$$^^^@@@~~~\ comment here

:-)

NB: I use a German server which is pretty good, but (in common with most
Usenet servers, I gather) it doesn't get everything posted to comp.lang.ada;
I didn't get Simon's most recent reply to me in this thread. So if my
comments appear disjointed in this way, you know why.

:-( ;-)

--
Best wishes,
Nick Roberts