Re: Ada safety road Was: Which is right ...

["Vladimir Olensky" <vladimir_olensky@yahoo.com>]

Robert Dewar wrote in message <7jvakl$nqi$1@nnrp1.deja.com>...
>In article <929221844.567.59@news.remarQ.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:


>> As a matter of fact I was talking  "about such kind of
>document " that I had
>> in mind   when I did not know about N359.
>> I could not  agree  that writing reliable software is
>> specialized area.
>> Just contrary I think that this is universal area.



>There is a big difference between high integrity software
>(yes, most certainly safety critical is a little too
>restrictive) and the general notion of reliable software.
>
>All software should be written in a reliable manner, and using
>techniques that promote reliability.
>
>The danger of making the jump from high integrity to realiable
>with such facility, is that the next thing you know, managers
>decide that the kind of restrictions that are suggested in the
>HRG document are appropriate for general purpose programming
>if "realiability" is important. Since reliability is ALWAYS
>important this will mean that we get more of the disease of
>arbitrarily forbidding critical Ada constructs under the
>illusion that it helps!


>I have more than once run into situations where people write
>a chunk of a program in C because some nitwit manager has
>forbidden the use of (e.g.) unchecked conversion completely.


There are managers and managers.
We have here one saying that tells that "manager_position +
manager_knowledge=CONSTANT" that just confirms what you said above. Of
course it is not an universal law but it has some connection to reality.
And of course it is easily  explained.


>
>Remember that the HRG has a very restrictive mandate. As it's
>name implies it is in the specific business of looking at issues
>related to Annex H, the Safety and Security annex of the
>standard. It is not at all the case that the document at hand is
>in any sense a general prescription for all Ada programming, and
>if people read it with this (mis)understanding, then it is a
>pity, because this very valuable (in context) document may end
>up resulting in some significant negative effects.
>


I think that there should not be black and white approach.
There should be just full understanding and feeling of all things that may
cause problems.
Clearly defined  design goals also help to define appropriate approach to
resolve them.
Here one association comes up to my mind - combination of M3 opaque types
and UNSAFE modules that help to avoid black and white approach.


>
>Validimir, it was you who said you thought the HRG document
>could be more comprehensive -- what did you mean?

>So there's the question Vladimir -- to make your position VERY
>clear, explain your criticism of the HRG document, namely that
>it is not comprehensive, by giving examples where you think it
>is lacking.


I was not criticizing N359 at all.  Instead I stated that it is an excellent
document.
When I didn't new about it I was thinking that there is a need in document
that covers all aspects of possible erroneous execution of Ada program
(including some number of examples). Check my previous posts.
So I was talking not about HRG document. I was talking what I had in mind.
When I was given reference to N359 I found that it is up to almost all my
expectation about such paper.
One should not expect more from ISO official document.  It is not a tutorial
it is a guidance.


Regards,

Vladimir Olensky