Which is right here - GNAT or OA ?

Which is right here - GNAT or OA ?

[Vladimir Olensky]

----------------------------------
--  Which is right here - GNAT or OA ?
---------------------------------

Recently I found some time to prepare for "AdaPower" some
"touch and feel" examples (just brushing up my old exercises) on
using controlled types for user defined GB which could be useful
for people learning Ada. It is one of the ways to attract new
people to Ada by explaining very simply some things
that may seem very difficult.

I mentioned about my simple user GB examples few months ago in GB
thread but then I had no time to prepare them for open use.
Then there was nice article about smart pointers by
Mathew Heaney describing the same issue and I did not feel like
adding anything else to this subject.
Then AdaPower come to the  existence (thanks to David Button)
and I felt that it is better late than never.

While working on that examples  I also was preparing some
introductory examples where I tried to put light on some things
that may be unclear to the beginners.

One of these intro examples is the effect of using
Ada.Unchecked_Deallocation for pointers referencing
different types of objects and objects allocated differently.
(one  may have a list of objects that are allocated differently
and he/she wants that the same operations on the items of this list
would have the same effect)

To my surprise I found that GNAT 3.11p and OA (ObjectAda Special
Edition version 7.1.424) give different results for the same test  under
Windows 98.

Here is this example :

------------------------------------------------------
-- Author: Vladimir Olensky, May 1999
--
-- This example shows what happens when you are
-- trying to deallocate static tagged object ( non controlled)
---------------------------------------------------------
with Ada.Unchecked_Deallocation;
with Ada.Text_Io; use Ada.Text_Io;
with Ada.Integer_Text_Io; use Ada.Integer_Text_Io;
procedure Tst_A4 is

   Type Q is record
      ID:Integer:=0;
   end record;

   type Q_A is access all Q;

   procedure Free is new
       Ada.Unchecked_Deallocation(Q,Q_A);

    -- statically declared  object
    q1: aliased Q;
    q_ptr:Q_A;

begin
   q1.ID:=10;
   q_ptr:=q1'Access;

   Put(" Object ID = ");
   Put( (q_ptr.all.ID),2);
   New_Line;
   Put_line("-----------------------------------");

-- Statement_1:
   free(q_ptr);
-------------------
   q1.ID:=20;
   Put(" Object ID = ");

-- Statement_2:
   Put( (q1.ID),2);
-------------------
   New_Line;
   Put(" q_ptr Object ID = ");

-- Statement_3:
   Put( (q_ptr.all.ID),2);
----------------------------------

   New_Line;

end Tst_A4;

*******************************************
In this test we have:

GNAT: - executing statement_1 with no problems.
  after that we have:
  1. q_ptr=null
  2. q1 continue to exists
  As a result GNAT is executing Statement_2 with no problems
  and printing "Object ID = 20" and  then raising
  CONSTRAINT_ERROR exception at Statement_3
  (it should be so as q_ptr=null)

OA:  - raising exception at Statement_1:

For me the right behavior of the Ada.Unchecked_Deallocation for
pointer to statically allocated object (regardless of what RM is
saying now) would be not to try to deallocate static object of any
type - tagged or not tagged, controlled or uncontrolled and assign
null value to pointer for which Ada.Unchecked_Deallocation was invoked.

Why there is no such thing in RM Section 13.11.2 after paragraph 9 ?
Were there any reasons not to describe this case?

To me GNAT behavior is better than OA though is not consistent.
( for controlled types  GNAT behaves differently - it raises
   PROGRAM_ERROR : EXCEPTION_ACCESS_VIOLATION).

RM Section 13.11.2 does not describe clearly and explicitly this case
so there is no wonder that the two best compiles behave differently.

It is interesting if similar test is included in Ada compiles validation
procedures.


It would be interesting to hear comments regarding this issue.

Regards,

Vladimir_Olensky

Re: Which is right here - GNAT or OA ?

[Robert Dewar]

In article <928083159.436.79@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:

This is definitely an RTFM case. The RM says

16   Evaluating a name that denotes a nonexistent object is
erroneous.  The execution of a call to an instance of
Unchecked_Deallocation is erroneous if the object was created
other than by an allocator for an access type whose pool is
Name'Storage_Pool.

So this programs is erroneous, and given that, OA and
GNAT behave identically, namely they give unpredictable
results.

No other definition would make sense in the language, you don't
want lots of elaborate checks going for an "unchecked" feature!

Note that you have to be careful in the ase of controlled
objects not to try to free statically allocated stuff. This
is a user responsibility in writing the Finalize routine!

Various tools will detect an attempt to free something that
has never been allocated. For example the gnatmem tool supplied
with GNAT will immediately detect that your program here is
wrong.



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Which is right here - GNAT or OA ?

[Florian Weimer]

"Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:

> RM Section 13.11.2 does not describe clearly and explicitly this case
> so there is no wonder that the two best compiles behave differently.

Well, actually it does (see RM 13.11.2(16)):

| The execution of a call to an instance of Unchecked_Deallocation is
| erroneous if the object was created other than by an allocator for an
| access type whose pool is Name'Storage_Pool.

So in fact, there's no contradiction, although the two compilers behave
differently.

I don't think the language designers could have specified anything
but erroneous execution in this case.  For example, it is very
complicated to detect that the value of an Access attribute of an
aliased record component is not a valid argument for a given instance
of Ada.Unchecked_Deallocation if the record itself has been created by
an allocator.  Simple heuristics based on the machine address of the
object in question clearly do not work here.

Another but related thing surprises me---it's AARM 12.5.4(4.a):

| If no _modifier applies to the formal, then the actual type may be
| either a pool-specific or a general access-to-variable type.

I can't imagine any reason why an access-to-variable type should be
allowed as an actual parameter for a formal access type without an
`all' modifier.  If this was changed, an access-to-variable would not be
allowed as a parameter in an instantiation of Ada.Unchecked_Deallocation,
which seems quite reasonable to me.  (I don't claim that the language
definition inadequate here, I simply can't make sense out of it, which
is very likely my own fault. ;)

Re: Which is right here - GNAT or OA ?

[Vladimir Olensky]

Robert Dewar wrote in message <7is6pt$8cd$1@nnrp1.deja.com>...
>In article <928083159.436.79@news.remarQ.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>
>Note that you have to be careful in the ase of controlled
>objects not to try to free statically allocated stuff. This
>is a user responsibility in writing the Finalize routine!
>


  That's right  and the very  purpose of this small example (one among some
others)  was to to illustrate why  it is necessary distinguish between
statically allocated and dynamically allocated objects  when using
controlled types for user defined automatic objects deallocation (GB)  to
provide proper program behavior.
I doing this in other examples and this one is explaining why it is
necessary.

I mentioned that I am doing such checks  few months ago in the thread
related to Garbage Collection that arise from time to time here. At  that
time I was wondering if it possible for compiler itself to provide some
additional  compile time info so that RTS could perform such check later
without necessity to do it manually.  I still think that it is possible and
that this is one of the necessary steps on the way of implementing full
featured GB.  Even without system GB  it can make life easier for
programmers.


  As I mentioned I did this stuff  long time ago and now I want to put some
pieces of code to Adapower as "touch and feel" ready to use examples of
using controlled  types. "Touch and feel" is one the best ways to explain
things.  Someone who wants to know can try "touch and feel" example  see the
output read short explanations end comments  and as a result he/she  will
have internal feeling related to that subject.


>So this programs is erroneous, and given that, OA and
>GNAT behave identically, namely they give unpredictable
>results.

As I explained in the first message and in here above it erroneous on
purpose.

It helps to explain why  one should  check if the variable is static prior
to attempt do deallocate it doing finalization (what is being done in my
other examples related to use of controlled types) .
I only  thought that both GNAT and OA will raise exception at  the same
Statement_1.

OA is raising exception  at  -- Statement_1: (   free(q_ptr));

but GNAT performing it without any complains and after that
pointer to that record  get NULL value but object continue to exists.

So at -- Statement_2:    Put( (q1.ID),2)  GNAT is extracting field from the
record and printing it without no problems.

Statement_3 was to show that when q_ptr has NULL value  exception should be
raised here.


-------------------


Regards,

Vladimir Ylensky

Re: Which is right here - GNAT or OA ?

[David Botton]

Thank you for the compliments! I am a big believer in learning through
example.

If you or any one tried to post new articles, or e-mail me yesterday
(5/30/99) from 8am to 10pm EST, I lost it and never saw it. There was a
glitch in some code I was writing to burn spam up that ended up burning
up all the mail. Sorry.

David Botton

In article <928083159.436.79@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> Recently I found some time to prepare for "AdaPower" some
> "touch and feel" examples (just brushing up my old exercises) on
> using controlled types for user defined GB which could be useful
> for people learning Ada. It is one of the ways to attract new
> people to Ada by explaining very simply some things
> that may seem very difficult.
>
> I mentioned about my simple user GB examples few months ago in GB
> thread but then I had no time to prepare them for open use.
> Then there was nice article about smart pointers by
> Mathew Heaney describing the same issue and I did not feel like
> adding anything else to this subject.
> Then AdaPower come to the  existence (thanks to David Button)
> and I felt that it is better late than never.
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Which is right here - GNAT or OA ?

[Vladimir Olensky]

Florian Weimer wrote in message ...
>"Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:
>
>I don't think the language designers could have specified anything
>but erroneous execution in this case.  For example, it is very
>complicated to detect that the value of an Access attribute of an
>aliased record component is not a valid argument for a given instance
>of Ada.Unchecked_Deallocation if the record itself has been created by
>an allocator.  Simple heuristics based on the machine address of the
>object in question clearly do not work here.


As a matter of fact this is amazingly simple. If I can do this check at a
run time myself  why RTS can not do the same ?
The cost of this is one  additional  hidden field in the type
representation which  is set to needed value during object creation.
 Soon I demonstrate this simple technique in set of "talking" examples that
are almost ready to be posted to AdaPower.
The same thing could be done by the compiler itself.  There even will be no
need to have additional public run time attributes.
Compiler or allocator sets  this field during object creation and  RTS can
check this field and do what needed depending on value of this  field upon
object deallocation request. This could be very handy.

>
>Another but related thing surprises me---it's AARM 12.5.4(4.a):
>
>| If no _modifier applies to the formal, then the actual type may be
>| either a pool-specific or a general access-to-variable type.
>
>I can't imagine any reason why an access-to-variable type should be
>allowed as an actual parameter for a formal access type without an
>`all' modifier.  If this was changed, an access-to-variable would not be
>allowed as a parameter in an instantiation of Ada.Unchecked_Deallocation,
>which seems quite reasonable to me.  (I don't claim that the language
>definition inadequate here, I simply can't make sense out of it, which
>is very likely my own fault. ;)

Yes, very interesting,  I agree, it does not go all along the line with Ada
strong type checking.
In some circumstances it may cause the same result that was demonstrated in
my small demo.

Regards,

Vladimir Olensky

Re: Which is right here - GNAT or OA ?

[Robert Dewar]

In article <928136551.707.11@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> As I explained in the first message and in here above it
> erroneous on purpose.

Sorry, Vladimir, but your message is still in the archives, we
don't have to rely on memory

  a) it made no mention of erreoneous

  b) it complained that the RM does not handle this case (it
     does, quite clearly)

  c) it complained that the behavior of OA and GNAT were
     different, and asked which is right (the subject of this
     thread is your invention). The complaint is invalid and
     the question is meaningless. You cannot make any comments
     or complaints about the behavior of an erroneous program
     execution or expect any consistency

  d) it suggested a semantics quite different from the RM for
     this case, one which would in fact be entirely impractical
     and certainly undesirable.

> It helps to explain why  one should  check if the variable is
> static prior to attempt do deallocate

This is highly misleading, you must do this check NOT because
different compilers happen to do different things, but because
it is erroneous not to do this check, as the RM clearly states.
The results of experiments with erroneous programs cannot
possibly have any legitimate influence whatsoever on how you
code your program.

> I only  thought that both GNAT and OA will raise exception at
> the same Statement_1.

That would tend to indicate that you do not understand what
erroneous means. Erroneous is a well defined technical term,
it does not just mean wrong, or improper. To expect or think
that compilers should or will behave consistently on erroneous
programs is to misunderstand the definition of erroneous.

> Statement_3 was to show that when q_ptr has NULL value
> exception should be raised here.

Nope! You cannot make ANY statement WHATSOEVER about
expectations form an erroneous program execution.



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Which is right here - GNAT or OA ?

[Robert Dewar]

In article <928174549.336.98@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> As a matter of fact this is amazingly simple.

No, doing this without adding unacceptable overhead is not
simple, and in fact is simply not practical.

> If I can do this
> check at a run time myself  why RTS can not do the same ?

Because the cost is too high

> The cost of this is one  additional  hidden field in the type
> representation which  is set to needed value during object
> creation.

Yes, and that cost is much too high, for example, if you have
a simple linked list type, you could be talking about adding
a storage overhead of 20-25%.

Surely you must realize your method is completely obvious! The
fact that the RM makes this situation erroneous is an explicit
indication that the designers of the language have considered
your solution and rejected it as introducing excessive overhead.

The design is very sensitive to avoiding unnecessary storage
use. FOr example, the confusing difference between:

   A : aliased constant String (1 .. 80) := " 80 chars ...";
   A : aliased constant String           := " 80 chars ...";

is solely to save the 8 bytes that would otherwise be required
for the bounds in the first case.





>  Soon I demonstrate this simple technique in set of "talking"
examples that
> are almost ready to be posted to AdaPower.
> The same thing could be done by the compiler itself.  There
even will be no
> need to have additional public run time attributes.
> Compiler or allocator sets  this field during object creation
and  RTS can
> check this field and do what needed depending on value of this
field upon
> object deallocation request. This could be very handy.
>
> >
> >Another but related thing surprises me---it's AARM
12.5.4(4.a):
> >
> >| If no _modifier applies to the formal, then the actual type
may be
> >| either a pool-specific or a general access-to-variable
type.
> >
> >I can't imagine any reason why an access-to-variable type
should be
> >allowed as an actual parameter for a formal access type
without an
> >`all' modifier.  If this was changed, an access-to-variable
would not be
> >allowed as a parameter in an instantiation of
Ada.Unchecked_Deallocation,
> >which seems quite reasonable to me.  (I don't claim that the
language
> >definition inadequate here, I simply can't make sense out of
it, which
> >is very likely my own fault. ;)
>
> Yes, very interesting,  I agree, it does not go all along the
line with Ada
> strong type checking.
> In some circumstances it may cause the same result that was
demonstrated in
> my small demo.
>
> Regards,
>
> Vladimir Olensky
>
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Which is right here - GNAT or OA ?

[dennison]

In article <7iu2oj$gvh$1@nnrp2.deja.com>,
  David Botton <dbotton@my-deja.com> wrote:

> If you or any one tried to post new articles, or e-mail me yesterday
> (5/30/99) from 8am to 10pm EST, I lost it and never saw it. There was
a
> glitch in some code I was writing to burn spam up that ended up
burning
> up all the mail. Sorry.

For just that reason, my filter doesn't delete email tagged as "spam".
It just tosses it in a "junk" drawer, to be perused at my leisure. Every
now and then an important message makes its way in there.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Which is right here - GNAT or OA ?

[dennison]

In article <7is6pt$8cd$1@nnrp1.deja.com>,
  Robert Dewar <robert_dewar@my-deja.com> wrote:
> So this programs is erroneous, and given that, OA and
> GNAT behave identically, namely they give unpredictable
> results.

Yikes. I hope I haven't set a bad trend here in posting a couple of
queries about why Gnat and OA don't handle the same constructs in the
same way. A fair bit about Ada is still implementation dependent. And of
course whenever you (ab)use UNCHECKED_anything, all bets are off. There
are certianly situations where its OK for different compilers to behave
differently.


--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Which is right here - GNAT or OA ?

[Tucker Taft]

Florian Weimer wrote:
> ...
> Another but related thing surprises me---it's AARM 12.5.4(4.a):
> 
> | If no _modifier applies to the formal, then the actual type may be
> | either a pool-specific or a general access-to-variable type.
> 
> I can't imagine any reason why an access-to-variable type should be
> allowed as an actual parameter for a formal access type without an
> `all' modifier.  If this was changed, an access-to-variable would not be
> allowed as a parameter in an instantiation of Ada.Unchecked_Deallocation,
> which seems quite reasonable to me.  (I don't claim that the language
> definition inadequate here, I simply can't make sense out of it, which
> is very likely my own fault. ;)

You may be parsing the sentence incorrectly.  It is saying that the
actual type may be a (pool-specific or general) access-to-variable
type.  It certainly must be an access-to-variable type, unless
the "constant" modifier is present.  By omitting the "all" modifier,
you are allowing either kind of access-to-variable type, pool-specific
or general.  Within the generic unit, the formal type is considered
pool-specific.  This works because the capabilities of a pool-specific
access type are a subset of the capabilities of a general access type.

This is analogous to the way "limited" is used in generic formal types.
If present, either a limited or a non-limited actual type is used.
If the word "limited" is absent, then only a non-limited actual
type may be used.  In general, a formal type specifies the minimum
set of properties required.  It is safe to provide an actual type
with more properties than what is presumed for the formal.

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

Re: Which is right here - GNAT or OA ?

[Matthew Heaney]

"Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:

> ----------------------------------
> --  Which is right here - GNAT or OA ?
> ---------------------------------

Both are, because the language doesn't specify what happens when you
try to deallocate an object on the stack.  Your code is erroneous.

 
> I mentioned about my simple user GB examples few months ago in GB
> thread but then I had no time to prepare them for open use.  Then
> there was nice article about smart pointers by Mathew Heaney
> describing the same issue and I did not feel like adding anything else
> to this subject.

My philosophy is to declare the type in such a way so that the user has
to use the type's allocator, and can't declare the object on the stack:

  type T (<>) is limited private;
 
  type T_Access is access all T;


  function New_T return T_Access;

  procedure Free (O : in out T_Access);

  procedure Op1 (O : access T);


Using this technique, the problem you describe cannot happen.

Re: Which is right here - GNAT or OA ?

[Vladimir Olensky]

Robert Dewar wrote in message <7iuqkc$ln6$1@nnrp1.deja.com>...

>> The cost of this is one  additional  hidden field in the type
>> representation which  is set to needed value during object
>> creation.
>
>Yes, and that cost is much too high, for example, if you have
>a simple linked list type, you could be talking about adding
>a storage overhead of 20-25%.


I fully agree about additional cost and it may be even higher.
But for  types which size is more than 100 bytes the cost will be less than
4%.
So if compiler could provide such runtime supports for objects marked  for
example as TRACED  (just contrary  to Modula-3 UNTRACED to exclude
selected objects from GB process)  than it could reduce the list of
situations when Ada program peforms erroneous execution.
I do not think that this is bad.

>Surely you must realize your method is completely obvious! The
>fact that the RM makes this situation erroneous is an explicit
>indication that the designers of the language have considered
>your solution and rejected it as introducing excessive overhead.

Of course I realize that it is very obvious. It is first_come_to_mind
solution for
user built types in situations when there is no  compiler support for that
and I agree that  it is not very suitable to be built into compiler.

Compiler implementation could be handled completely differently.
Each program has several memory areas (at least three - CODE, DATA and
STACK).

Compiler can same create special  record  with  the fields CODE_START,
CODE_END,
STACK_START, STACK_END, PROGRAM_STATIC_DATA1_START,
PROGRAM_STATIC_DATA1_END, PROGRAM_STATIC_DATA2_START,
PROGRAM_STATIC_DATA2_END etc.
Compiler and linker have all the information to be able to do this.

When Free(X) is invoked then RTS  could do something like this  (in reality
it may be much more complex):

If    (X_referenced_ object_Address   NOT in CODE_ADDRESS_RANGE)  and then
      (X_referenced_ object_Address   NOT in STACK_ADDRES_RANGE) and then
      (X_referenced_ object_Address   NOT in STATIC_DATA_ADDRESS_RANGE)  and
then
      (all  other necessary checks)   then
       Deallocate_Referenced_Object;  -- or raise name_exception here to be
close to RM
      X:=null;
else
     X:=null;
end;

Such solution have very little  overhead and it is not very difficult to
be implemented.

Such thing could be turned on/off by compiler pragma in order not to
introduce anything in language definition.

Doing so it is possible reduce the number of situation when Ada program can
perform erroneous execution (with unpredictable effect).

Again there is nothing new in this. Similar technique was used earlier in
assembler programming for many purposes. (e.g. old DOS TSR programs used to
calculate it's code size (CODE_END-CODE_START) to allocate themselves into
computer memory)


>The design is very sensitive to avoiding unnecessary storage
>use. For example, the confusing difference between:
>
>   A : aliased constant String (1 .. 80) := " 80 chars ...";
>   A : aliased constant String           := " 80 chars ...";
>
>is solely to save the 8 bytes that would otherwise be required
>for the bounds in the first case.


This  is indeed very interesting example.
 I think it ( and a bit of assembler code)  could be placed in AdaPower in
section named  something like "Ada Tips and Tricks".

-----------------------------------------------------------
procedure Ada_Rts is
   a : aliased constant String (1 .. 10) := "1234567890";
   b : aliased constant String := "1234567890";
begin
   null;
end Ada_Rts;
----------------------------------------------------------
gcc2_compiled.:
___gnu_compiled_ada:
..text
LC0:
..ascii "1234567890\0"
..data

_a.0:
..ascii "1234567890"
..text
..align 4

_b.1:
..long 1
..long 10
..ascii "1234567890"
..space 2
..align 4

..globl __ada_ada_rts
__ada_ada_rts:
pushl %ebp
movl %esp,%ebp
movl %ebp,%esp
popl %ebp
ret
---------------------------------------------------


Such optimization is extremely important for embedded applications.



In practice there exist general use applications running on top of different
OSs.

For them  small overhead does not make much difference.
Executable size for the above example with GNAT 3.11p for Windows NT is 110
kb.
So adding to it some amount of  code won't make any difference.

Another thing that is worth to the importance of  how compiler and linker
work together in order to provide minimum executable size by cutting off
unused code.


 For example Windows demo Keylook that was built using GNAT with  -O3  has
size of  378 Kbytes.
And this was using  only thin Win32 bindings.

  MS VC98  simple Win32 application with menus ,dialogs (direct calls to Win
APIs - without  MFC)  has size of  only 28 kb.

 Building simple  application using Claw  & GNAT  results in executable size
above 1.5Mb.

 Simple Win32 application that uses MFC (MS OOP Win32 libraries)  has size
of 252 kb when MFC libraries are statically linked to the executable.
When MFC is used as shared DLL the exe size is 28 kb.

This comparison shows where one should  be talking about size overhead.

It seems that GCC linker links everything contained in packages  WITHed to
main program.

This is problem of the compiler-linker cooperation in producing smallest
possible code.
I understand that GNAT here has more difficult situation with GCC linker
than other compiler vendors with their own  linkers.

Please take me right.  I am not complaining about GNAT.
I just trying to show that when we are talking about overhead and cost of
additional memory usage to perform some system tasks we should have broader
view on things.

One thing is  when we are talking about embedded systems where Ada is
running sometimes on a bare hardware or it is using small size RTS tailored
to particular requirements .

When we are talking about  general purpose Win32 app ( or Unix app maybe)
that uses a lot of standard libraries then situation is different.

Of course I know about Gnatelim and I played with it some time ago. I found
it not very convenient for me.
I tried it with test application that uses Claw .   It can take several
iterations and results in hour or more of waste time to obtain some small
reduction of file size. STRIP in GNAT3.10 was much more convenient.

I think that this work should be performed by compiler-linker tandem.

Please do not tell me that I am complaining !
This is just my personal considerations that may be different from other's.

That was not me who started talking about memory overhead.

 --------------------------------------------------------------

> Share what you know. Learn what you don't.

I like this phrase and  I completely agree with it.
It  is very constructive.
It could  be used as motto for c.l.a.


Best regards,

Vladimir Olensky

Re: Which is right here - GNAT or OA ?

[Vladimir Olensky]

Vladimir Olensky wrote in message <928529202.956.79@news.remarQ.com>...

>If    (X_referenced_ object_Address   NOT in CODE_ADDRESS_RANGE)  and then
>      (X_referenced_ object_Address   NOT in STACK_ADDRES_RANGE) and then
>      (X_referenced_ object_Address   NOT in STATIC_DATA_ADDRESS_RANGE)
and
>then
>      (all  other necessary checks)   then
>       Deallocate_Referenced_Object;  -- or raise name_exception here to be
>close to RM
>      X:=null;
>else
>     X:=null;
>end;


Sorry,  I clicked my mouse in the wrong place. I should be:

If    (X_referenced_ object_Address   NOT in CODE_ADDRESS_RANGE)  and then
      (X_referenced_ object_Address   NOT in STACK_ADDRES_RANGE) and then
      (X_referenced_ object_Address   NOT in STATIC_DATA_ADDRESS_RANGE)  and
then
      (all  other necessary checks)   then
             Deallocate_Referenced_Object;
             X:=null;
else
            X:=null;  -- or raise name_exception here to be close to RM
end;

Regards,
Vladimir Olensky

Re: Which is right here - GNAT or OA ?

[Robert Dewar]

In article <928569312.951.42@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>
> Vladimir Olensky wrote in message
<928529202.956.79@news.remarQ.com>>

<<simple scheme based on address range comparisons snipped>>

Obviously you cannot require such a scheme, because of course
it is inapplicable in many environments, especially with
multi-threading.

Even in environments where it might be practical, it's more
expensive than you think, because some of these ranges are
tasks specific data.

In any case, this kind of approach is certainly completely
familiar, and it would not be invalid for a compiler to
implement it, but it seems a waste of time and space to me
to attempt to guard against this kind of logic error in a
language that does not even handle the uninitialized variable
problem completely (and that too is of course quite a
deliberate decision).

It is certainly not something we would consider adding to
GNAT in any environments.

Generally the notion of erroneous in the RM is that you should
detect it if it is free or cheap, but NOT add extra code for
this kind of detection.

Yes, it could be under some kind of debugging pragma, but if
you are going to move in that direction, you want to go much
further, and in particular handle the uninitialized variable
problem, and other, much more common, and much more worrisome
cases of erroneous access.

Deallocation of static stuff is in fact a pretty easy error
to guard against, since most typically this is done in well
controlled finalization routines in any case, and it is just
a matter of having the discipline to worry about this problem
and take proper care of it when you write the finalization
routine.

And to repeat, since you keep repeating the subject, both
GNAT and OA are right here, and do what the RM intends!


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Which is right here - GNAT or OA ?

[Florian Weimer]

"Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:

> When Free(X) is invoked then RTS  could do something like this  (in reality
> it may be much more complex):

[Heuristics based on the internal access value representation snipped]

> Such solution have very little  overhead and it is not very difficult to
> be implemented.

Maybe that's true, but it does not work.  Consider the following
situation:

   type A is record
      X: Integer;
   end record;

   type B is record
     Y: aliased A;
   end record;
   
   type B_Access is access B;

   Z: B_Access := new B;
                        
Your heuristics fails for Z.Y'Access, because this access
value references an object which has been created indirectly by
an allocator.  On all architectures I can imagine, the internal
machine representation of Z.Y'Access will look very like that of an
access to an object which has been directly created by an allocator,
although the value of Z.Y'Access certainly isn't a valid argument for
Ada.Unchecked_Deallocation.

Of course, it is possible to ensure that Ada.Unchecked_Deallocation
raises an exception if it encounters an access-to-variable, but this
requires some non-trivial changes.  A few possible implementations come
to my mind: colored pointers, fat pointers, hidden record fields (your
suggestion; problematic with scalar types and possibly with records
with representation clauses, also some space concerns), colored tags
for tagged records, support from a garbage collector.  They all don't
seem very appealing to me and probably won't handle all kinds of Ada
objects consistently (except perhaps garbage collection ;).

One very reasonable way to solve this kind of problem was already
pointed out: Use an abstract data type which hides allocation and
deallocation details in the implementation.  This way, you never have to
call Ada.Unchecked_Deallocation directly (outside the implementation,
of course), and you can't accidently deallocate an object which isn't
located in a storage pool.

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

[Larry Kilgallen]

In article <928703068.617.98@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:

> But  I see  one problem here.  All this information is scattered around  RM.

In order to be definitive, the RM should not duplicate information in
various locations, and thus cannot be in the ideal exposition format
for all purposes.

> I think that to facilitate safety programming such info should be gathered
> into one paper
> with explanations why it was not possible to overcome such situations  and
> it should contain many examples covering different aspects that leads to
> erroneous execution. There should be no indirect references ("other then
> ...."). Everything should be directly described  and should be as simple as
> possible.
> I see it as some kind of "Ada safety programming roadmap".  And of course
> such paper should be easily available online for all interested in it. So
> far I have not seen such document available online .

Perhaps it is in a published book, or in one yet to be written -- perhaps
by you.  In another area, "Concurrency in Ada" has won high praise,
even though it is a real book rather than just some ephemeral web site.

Larry Kilgallen

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

[Robert Dewar]

In article <928703068.617.98@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:

> I was just thinking about different aspects of providing some
> general kind of "foolproofness" to program written in Ada in
places where RM
> define program behavior as erroneous.
> I think nobody would like to be on a plane that performed
> erroneous flight
> """' ' '  ^~\_+.
> Anyone would prefer to be accidentally on board of the wrong
> flight instead.

Don't worry, safety critical software of this type is certified,
and typically written in a small safe subset of Ada. It would
be VERY unusual to allow Unchecked_Deallocation *at all* in
such an application, and if it was allowed, it would have to
verified that all possible calls were safe.

It is VERY important for Ada programmers to be aware of the
situations which lead to erroneous programs. You can easily
search through the RM to find all such cases.

In fact I will repeat again my thought here. This is a VERY
marginal case of erroneousness. If you want to get into the
business of writing a "checkout" compiler that spends extra
time and space to check for as many erroneous situations as
possible, this is not at the top of the list for cases that
are useful to check!

Remember though, that runtime checks, while very useful, are
not a panacea.

I don't want to be on a plane that executes erroneous code,
but I also don't want the captain to get a message saying
that Constraint_Error was raised at such and such a location :-)
(in fact run time checks are in my experience usually turned
off for safety critical code, since they cause trouble with
deactivated code in verification protocols).


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

[Vladimir Olensky]

Pascal F. Martin wrote in message ...
>In article <7jf1ik$8v6$1@nnrp1.deja.com>,
> Robert Dewar <robert_dewar@my-deja.com> writes:
>> In article <928703068.617.98@news.remarQ.com>,
>>   "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>>
>>> I was just thinking about different aspects of providing some
>>> general kind of "foolproofness" to program written in Ada in
>> places where RM
>>> define program behavior as erroneous.
>>> I think nobody would like to be on a plane that performed
>>> erroneous flight
>>> """' ' '  ^~\_+.
>>> Anyone would prefer to be accidentally on board of the wrong
>>> flight instead.
>>
>> [...]
>>
>> I don't want to be on a plane that executes erroneous code,
>> but I also don't want the captain to get a message saying
>> that Constraint_Error was raised at such and such a location :-)
>
>I remember that the first Ariane 5 rocket had been lost when
>an Ada program did hit a runtime check ! The exception was not
>the cause of the problem (it was a design error), but it made
>the rocket crash.
>
>Sometime, it make sense to ignore errors and continue on.
>Constraint_Error is for developpers, not for users, and
>a program cannot be in "debug mode" forevever.


I remember that report. Some parameters went out of the limits that were set
for Ariane 4. These limits were not changed for Ariane 5 though it was
equipped with the new engines and  operation conditions during launch time
were quite different. But needed software tests for new operational
conditions were not performed properly and we have seen the results.

I fully agree that most of the run time checks are usually used in debug
mode and they serve  for application testing.
In release mode most of them are usually  turned off. So most of the
developing systems provide ability to set parameters for each mode
independently and create any additional configuration profile if needed.
The more could be done in debug mode the less possibility that something
could sneak into release mode.

Anyway it was just a  joke with some hyperbolic meaning.
Record extracted from the plane black
box just confirms that: """' ' '  ^~\_+.

Regards,
Vladimir Olensky.

Ada safety road Was: Which is right ...

[Vladimir Olensky]

Robert Dewar wrote in message <7jb1l9$694$1@nnrp1.deja.com>...


>And to repeat, since you keep repeating the subject, both
>GNAT and OA are right here, and do what the RM intends!


Sorry, It just didn't come up to my mind to change the subject.
Even original subject was not very adequate to what I had in mind
I really did not had intention on insisting which is better in following RM.


I had other things in mind.


I was just thinking about different aspects of providing some
general kind of "foolproofness" to program written in Ada in places where RM
define program behavior as erroneous.
I think nobody would like to be on a plane that performed erroneous flight
"""' ' '  ^~\_+.
Anyone would prefer to be accidentally on board of the wrong flight instead.

One good aspect of Ada is that when it is impossible to provide compiler
solution to some problems (due to implementation cost and some other reasons
that may not be  very obvious) LRM at least honestly specifies situations
when erroneous execution is possible.

But  I see  one problem here.  All this information is scattered around  RM.

I think that to facilitate safety programming such info should be gathered
into one paper
with explanations why it was not possible to overcome such situations  and
it should contain many examples covering different aspects that leads to
erroneous execution. There should be no indirect references ("other then
...."). Everything should be directly described  and should be as simple as
possible.
I see it as some kind of "Ada safety programming roadmap".  And of course
such paper should be easily available online for all interested in it. So
far I have not seen such document available online .
If you crossing mine field and you do not have good map with red marks on it
all your life depends on your luck :-)
Such type of documents are usually top level  documents in design of any
safety critical system (at least it was in my experience).

I recently put  together all that staff  from RM  and I should mention that
this list is not very short.
So I was wondering if it is possible to do something on compiler level to
make this list shorter.

Almost five ears left since adoption of Ada 95  standard. Computing power
has increased almost tenfold since then (CPU speed, memory access time,
memory density etc.).  Some things that were costly to implement then may
have much less cost now.

Here I would like to add one more thing.
In many disputes Ada is described as mostly reliable language which allows
to catch almost all errors at compile time and others at a run time by
raising exceptions. This can  create some kind of trap for those starting to
use Ada ( to forget about cases of erroneous execution or not to pay
attention to them)
(e.g. typical comparisons between  C&C++ and Ada pointers from which the
reader may have wrong impression that Ada fully safe in this respect and as
a result not to pay proper attention to that issue. For me the most safe in
this area  is Modula-3 for very well known reasons).

Regards,

Vladimir Olensky

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

[Pascal F. Martin]

In article <7jf1ik$8v6$1@nnrp1.deja.com>,
	Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <928703068.617.98@news.remarQ.com>,
>   "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> 
>> I was just thinking about different aspects of providing some
>> general kind of "foolproofness" to program written in Ada in
> places where RM
>> define program behavior as erroneous.
>> I think nobody would like to be on a plane that performed
>> erroneous flight
>> """' ' '  ^~\_+.
>> Anyone would prefer to be accidentally on board of the wrong
>> flight instead.
> 
> [...]
> 
> I don't want to be on a plane that executes erroneous code,
> but I also don't want the captain to get a message saying
> that Constraint_Error was raised at such and such a location :-)

I remember that the first Ariane 5 rocket had been lost when
an Ada program did hit a runtime check ! The exception was not
the cause of the problem (it was a design error), but it made
the rocket crash.

Sometime, it make sense to ignore errors and continue on.
Constraint_Error is for developpers, not for users, and
a program cannot be in "debug mode" forevever.

-- 

Pascal F. Martin.

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

[Keith Thompson]

kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> In article <928703068.617.98@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:
> > But I see one problem here.  All this information is scattered
> > around RM.
> 
> In order to be definitive, the RM should not duplicate information in
> various locations, and thus cannot be in the ideal exposition format
> for all purposes.

The RM already has several "informative" annexes, which are not
strictly part of the standard.  Annexes K (attributes) and L (pragmas)
are particularly useful, even though (or rather *because*) they
duplicate information scattered around the RM.  An informative annex
listing all occurrences of erroneous execution and bounded errors
would have been useful.

As I was writing this, I realized we already have the next best thing.
The entry for "erroneous" in the RM's index refers to all the places
in the RM where the term is used; likewise for "bounded error".

This brings up a pet peeve of mine: the word "erroneous" was a poor
choice of terminology.  It's an existing English word with a
well-defined meaning.  When I use the word in an Ada context, I very
often have to explain the Ada-specific meaning.  It also fails to make
it clear that it's the execution of a construct that's erroneous, not
the construct itself.  Norman Cohen, in his book "Ada as a Second
Language", uses the phrase "unbounded error", which is much clearer.
Another good term is "undefined behavior", used by the C and C++
standards for (essentially) the same concept.

If we could keep people from using the word "erroneous" outside the
phrase "erroneous execution", there wouldn't be as much of a problem,
but that's not going to happen.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
One of the great tragedies of ancient history is that Helen of Troy
lived before the invention of the champagne bottle.

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

[Hyman Rosen]

Keith Thompson <kst@cts.com> writes:
> This brings up a pet peeve of mine: the word "erroneous" was a poor
> choice of terminology.
...
> Another good term is "undefined behavior", used by the C and C++
> standards for (essentially) the same concept.

If you follow the C++ newsgroups, you'll soon see that the same sort of
people who are confused about "erroneous" are confused about "undefined"
as well. They tend to mix it up with "implementation-defined", and get
quite indignant when no one offers them any sympathy :-)

For waht it's worth, I like "erroneous" better - it conveys to me the
sense that I have done something wrong, whereas "undefined" conveys to
me the sense that the language has forgotten something.

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

[Keith Thompson]

Robert Dewar <robert_dewar@my-deja.com> writes:
> In article <yecwvxfrb96.fsf@king.cts.com>,
>   Keith Thompson <kst@cts.com> wrote:
> > This brings up a pet peeve of mine: the word "erroneous" was a
> > poor choice of terminology.  It's an existing English word
> > with a well-defined meaning.  When I use the word in an Ada
> > context, I very often have to explain the Ada-specific
> > meaning.
> 
> The RM is *full* of ordinary english words used in a formal
> manner. You have to make clear that you are speaking this
> formal terminology when you do, and you should speak it only
> to the initiated :-)

Agreed.  I've just found that "erroneous" is the single most
troublesome example, probably because its normal English meaning is so
clearly applicable the same Ada code to which the technical term
applies.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
One of the great tragedies of ancient history is that Helen of Troy
lived before the invention of the champagne bottle.

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

[Robert Dewar]

In article <yecwvxfrb96.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> This brings up a pet peeve of mine: the word "erroneous" was a
> poor choice of terminology.  It's an existing English word
> with a well-defined meaning.  When I use the word in an Ada
> context, I very often have to explain the Ada-specific
> meaning.

The RM is *full* of ordinary english words used in a formal
manner. You have to make clear that you are speaking this
formal terminology when you do, and you should speak it only
to the initiated :-)

There are many cases where this can cause trouble, for example
how many people think a generic package is a package (it is
NOT, and this is critical in understanding the RM).


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

[Robert A Duff]

Keith Thompson <kst@cts.com> writes:

> The RM already has several "informative" annexes, which are not
> strictly part of the standard.  Annexes K (attributes) and L (pragmas)
> are particularly useful, even though (or rather *because*) they
> duplicate information scattered around the RM.

Annexes K and L are automatically generated from the scattered text
defining the various attributes and pragmas throughout the RM.

> As I was writing this, I realized we already have the next best thing.
> The entry for "erroneous" in the RM's index refers to all the places
> in the RM where the term is used; likewise for "bounded error".

In general, when I thought it would be useful to have a list of
something-or-others gathered together in one place, I chose to put it in
the index.  This is compact enough that I could freely put in lots of
useful lists, without worrying about making the document too big.

There is at least one bug, unfortunately: the list under "configuration
pragma" is missing pragma Discard_Names.

> This brings up a pet peeve of mine: the word "erroneous" was a poor
> choice of terminology. ...

I agree.  How many times have I had confusing discussions with non-Ada
people, because they thought "erroneous" and "illegal" just mean
"wrong", as opposed to a very particular kind of wrongness?!

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

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

[Robert A Duff]

Hyman Rosen <hymie@prolifics.com> writes:

> If you follow the C++ newsgroups, you'll soon see that the same sort of
> people who are confused about "erroneous" are confused about "undefined"
> as well. They tend to mix it up with "implementation-defined", and get
> quite indignant when no one offers them any sympathy :-)

Yeah, and I think the lesson for language designers is to try pretty
hard to avoid language features with unpredictable semantics.  It's not
feasible to *completely* avoid them, but Ada comes pretty close, and I
would prefer to get a little bit closer still.

> For waht it's worth, I like "erroneous" better - it conveys to me the
> sense that I have done something wrong, whereas "undefined" conveys to
> me the sense that the language has forgotten something.

But there's a huge difference between doing something wrong and having
the compiler nicely point that out (either at compile time or at run
time), and having totally unpredictable behavior, and "erroneous"
doesn't capture that distinction in its normal English sense.

There are few enough erroneous cases in Ada, that it would have been
reasonable to spell it out in a long phrase every time.  Something like,
"If <RM-ese for dangling pointer>, the program is incorrect.  The
implementation is not required to detect this error, neither at compile
time nor at run time.  If this error occurs, execution is totally
unpredictable."  And then put some verbiage in chapter 1 about how awful
"totally unpredictable" really is.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

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

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> The RM is *full* of ordinary english words used in a formal
> manner. You have to make clear that you are speaking this
> formal terminology when you do, and you should speak it only
> to the initiated :-)

There aren't many examples that are as misleading as "erroneous".

I object to calling that type in Standard "Integer", as if God created
only a few billion of them.  And then we have to invent a new name,
"universal integer" for God's integers.  Sheesh.

> There are many cases where this can cause trouble, for example
> how many people think a generic package is a package (it is
> NOT, and this is critical in understanding the RM).

This doesn't bother me -- this is the way English works, and the RM is
not being naughty here.  A would-be king is not a king.  A retired
plumber is not a plumber.  A bogus doctor is not a doctor.  A former
president is not a president.  A non-partisan is not a partisan.

On the other hand, "template" would be clearer than "generic".
In fact, the very first paragraph of chapter 12 says, "A generic unit is
template..."  ;-)

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

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

[Robert A Duff]

Robert Dewar <robert_dewar@my-deja.com> writes:

> It is VERY important for Ada programmers to be aware of the
> situations which lead to erroneous programs. You can easily
> search through the RM to find all such cases.

But it's not so easy to search through an Ada program to find all such
cases.  Some of them are global properties of the program.

Of the two problems: programmers not knowing the language, and
programmers who do know the language making mistakes anyway, I think the
latter is the one to worry about most.  The former can be solved by
education; the latter has no known (complete) solution.

> In fact I will repeat again my thought here. This is a VERY
> marginal case of erroneousness. If you want to get into the
> business of writing a "checkout" compiler that spends extra
> time and space to check for as many erroneous situations as
> possible, this is not at the top of the list for cases that
> are useful to check!

I agree.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

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

[Robert Dewar]

In article <wcc674yh8ut.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Hyman Rosen <hymie@prolifics.com> writes:

> Yeah, and I think the lesson for language designers is to try
> pretty hard to avoid language features with unpredictable
> semantics.

It is easy to get in semantic knots on this issue. For example,
it is reasonable to require a compiler to implement semantics
where it is not predictable from the language what semantics
will be implemented, but it is unreasonable to require a
compiler to implement unpredictable semantics (subtle but
important difference).

Once at an Algol-68 meeting, Gerhard Goos asked exactly what
undefined meant. Someone replied that it meant "unimaginable
chaos", whereupon, Gerhard enquired as to just exactly how he
was expected to implement "unimaginable chaos" in his compiler
:-)



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

[Keith Thompson]

Robert A Duff <bobduff@world.std.com> writes:
[...]
> There are few enough erroneous cases in Ada, that it would have been
> reasonable to spell it out in a long phrase every time.  Something like,
> "If <RM-ese for dangling pointer>, the program is incorrect.  The
> implementation is not required to detect this error, neither at compile
> time nor at run time.  If this error occurs, execution is totally
> unpredictable."  And then put some verbiage in chapter 1 about how awful
> "totally unpredictable" really is.

The folks over in comp.std.c have a good term term for this: "nasal
demons".  This originated when someone observed that when the compiler
encounters a construct with undefined behavior, it is legal for it to
make demons fly out of your nose.  See also the entry for "nasal
demons" in The Jargon File and/or _The New Hacker's Dictionary_.

Note that there's no implication that the compiler is *required* to
make demons fly out of your nose.

It's important to remember that one possible consequence of undefined
behavior (or erroneous execution) is for the implementation to
silently do exactly what you naively expected it to do.  This is often
the nastiest possibility, since any problems may not show up until
years later.

This is why the authors of Ada (both 83 and 95) made such an effort to
minimize the number of cases where this can happen, and to clearly
document the cases that couldn't reasonably be avoided.

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center  <http://www.sdsc.edu>                 <*>
One of the great tragedies of ancient history is that Helen of Troy
lived before the invention of the champagne bottle.

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

[Robert Dewar]

In article <375E9592.32DA0709@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> Robert Dewar wrote:
> Using an uninitialized variable is *not* erroneous in Ada 95.

OK, pedagogically correct, but let's see what the RM says

   11  If the representation of the object does not represent a
       value of
       the object's type, the semantics of operations on such
       representations is implementation-defined, but does not
       by itself lead to erroneous or unpredictable execution,
       or to other objects becoming abnormal.

OK, suppose that I have an implementation for the Alpha, where
the normal code for division by a small constant uses a jump
table depending on the constant value, and I do not feel like
doing a constraint check, e.g.

   subtype q is range 1 .. 5;
   qv : q;
   x : integer := ...
   r : integer := x / qv;

Now in my compiler documentation, the effect is implementation
defined, so let me define it. When the division operation is
executed, a four byte address is computed by loading the value
from a table ..... control is then passed to the code at this
four byte address. If the value is valid, the code will do the
required division, if the value is invalid, you must inspect the
generated object code to determine the actual code that will be
executed.

Very well defined! Completely predictable! Not erroneous!
Completely RM compliant! But not very helpful :-(

I perfectly well understand the attempt in the RM to cut back
on erroneousness here, but I am afraid it is a bit bogus in
this case.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

[Robert Dewar]

In article <yeclndu44z8.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:
> This is why the authors of Ada (both 83 and 95) made such an
> effort to minimize the number of cases where this can happen,
> and to clearly document the cases that couldn't reasonably be
> avoided.

I think more could have been done, particularly in the area
of uninitialized variables. For simple variables, I like the
CDL approach which says that there must not exist any static
paths through the program allowing a simple variable to be
undefined (i.e. no ud chain can reach from a reference to a
declaration with no initialization). This worked very well
in CDL in practice (CDL = Koster's Compiler Definition
Language).


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

[dennison]

In article <wcc674yh8ut.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:

> But there's a huge difference between doing something wrong and having
> the compiler nicely point that out (either at compile time or at run
> time), and having totally unpredictable behavior, and "erroneous"
> doesn't capture that distinction in its normal English sense.
>
> There are few enough erroneous cases in Ada, that it would have been
> reasonable to spell it out in a long phrase every time.  Something
like,
> time nor at run time.  If this error occurs, execution is totally
> unpredictable."  And then put some verbiage in chapter 1 about how
awful
> "totally unpredictable" really is.

I think we used to use the term "nasal monkeys" on c.l.a., to imply that
in this situation the compiler was free to cause monkeys to fly out of
the user's nose. Perhaps the RM should use that term. :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

[dennison]

In article <yeclndu44z8.fsf@king.cts.com>,
  Keith Thompson <kst@cts.com> wrote:

> The folks over in comp.std.c have a good term term for this: "nasal
> demons".  This originated when someone observed that when the compiler
> encounters a construct with undefined behavior, it is legal for it to
> make demons fly out of your nose.  See also the entry for "nasal
> demons" in The Jargon File and/or _The New Hacker's Dictionary_.

That's interesting. I wonder if that came about indepedently from
c.l.a.'s "nasal monkeys", or if one influenced the other.

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Entamology of "Nasal Demons"

[dennison]

In article <7jm185$mhf$1@nnrp1.deja.com>,
  dennison@telepath.com wrote:
> In article <yeclndu44z8.fsf@king.cts.com>,
>   Keith Thompson <kst@cts.com> wrote:
>
> > The folks over in comp.std.c have a good term term for this: "nasal
> > demons".  This originated when someone observed that when the
compiler
> > encounters a construct with undefined behavior, it is legal for it
to
> > make demons fly out of your nose.  See also the entry for "nasal
> > demons" in The Jargon File and/or _The New Hacker's Dictionary_.
>
> That's interesting. I wonder if that came about indepedently from
> c.l.a.'s "nasal monkeys", or if one influenced the other.

I just went and looked it up myself. The earliest reference I could find
to "making X fly out of Y's nose" was from a posting by Richard A.
O'Keefe <ok@cs.rmit.edu.au> on 1995/08/04 in comp.lang.c.moderated. It
may go back further than that, because dejanews doesn't keep
messages much older than that.

The first mention in comp.lang.ada was about 2 months later by
Dan.Pop@mail.cern.ch (Dan Pop) in a thread crossposted from several
other language newsgroups, including comp.lang.c. This is the post I
saw. It did indeed mention "demons", not "monkeys". I must have been
watching Wizard of Oz at the time. :-)

The term "nasal demons" seems to have first appeared in another thread
crossposted to c.l.a and c.l.c about 3 months later by Todd Knarr
<tknarr@xmission.com>

Deja is quite handy for wasting time in this manner. :-)

--
T.E.D.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

[Tucker Taft]

Robert Dewar wrote:
> 
> In article <yeclndu44z8.fsf@king.cts.com>,
>   Keith Thompson <kst@cts.com> wrote:
> > This is why the authors of Ada (both 83 and 95) made such an
> > effort to minimize the number of cases where this can happen,
> > and to clearly document the cases that couldn't reasonably be
> > avoided.
> 
> I think more could have been done, particularly in the area
> of uninitialized variables. 

Using an uninitialized variable is *not* erroneous in Ada 95.

> ... For simple variables, I like the
> CDL approach which says that there must not exist any static
> paths through the program allowing a simple variable to be
> undefined (i.e. no ud chain can reach from a reference to a
> declaration with no initialization). This worked very well
> in CDL in practice (CDL = Koster's Compiler Definition
> Language).

I presume that Ada 95 compilers that try to properly avoid unpredictable
behavior when an uninitialized variable is used do this kind of
tracking to determine whether the variable *might* be uninitialized,
and hence might be outside its declared range. 
Both GNAT and AdaMagic-based Ada 95 compilers seem to produce
"uninitialized variable" warnings these days.  At least in
the AdaMagic-based compilers, that information is used to
"bound" possible errors associated with using uninitialized variables, 
to avoid the dreaded erroneous/nose-demon situation.
 
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

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

[Markus Kuhn]

Peter Amey <pna@praxis-cs.co.uk> writes:
|> There certainly has been some work in this area.  At a pragmatic level
|> there is the Ada HRG which has produced (under auspices of ISO) a
|> guidance document on the use of Ada in high-intergrity systems.  The
|> document identifies language features and combinations of features which
|> are most likely to complicate reasoning about the behaviour of Ada
|> programs; clearly this includes behaviour which might be erroneous.

This document is freely available from

  http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf

Markus

-- 
Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

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

[Peter Amey]

Vladimir Olensky wrote:
> 
> Robert Dewar wrote in message <7jb1l9$694$1@nnrp1.deja.com>...
> 
> >And to repeat, since you keep repeating the subject, both
> >GNAT and OA are right here, and do what the RM intends!
> 
> Sorry, It just didn't come up to my mind to change the subject.
> Even original subject was not very adequate to what I had in mind
> I really did not had intention on insisting which is better in following RM.
> 
> I had other things in mind.
> 
> I was just thinking about different aspects of providing some
> general kind of "foolproofness" to program written in Ada in places where RM
> define program behavior as erroneous.
> I think nobody would like to be on a plane that performed erroneous flight
> """' ' '  ^~\_+.
> Anyone would prefer to be accidentally on board of the wrong flight instead.
> 
> One good aspect of Ada is that when it is impossible to provide compiler
> solution to some problems (due to implementation cost and some other reasons
> that may not be  very obvious) LRM at least honestly specifies situations
> when erroneous execution is possible.
> 
> But  I see  one problem here.  All this information is scattered around  RM.
> 
> I think that to facilitate safety programming such info should be gathered
> into one paper
> with explanations why it was not possible to overcome such situations  and
> it should contain many examples covering different aspects that leads to
> erroneous execution. There should be no indirect references ("other then
> ...."). Everything should be directly described  and should be as simple as
> possible.
> I see it as some kind of "Ada safety programming roadmap".  And of course
> such paper should be easily available online for all interested in it. So
> far I have not seen such document available online .
> If you crossing mine field and you do not have good map with red marks on it
> all your life depends on your luck :-)
> Such type of documents are usually top level  documents in design of any
> safety critical system (at least it was in my experience).
> 

[snip]

> Regards,
> 
> Vladimir Olensky


There certainly has been some work in this area.  At a pragmatic level
there is the Ada HRG which has produced (under auspices of ISO) a
guidance document on the use of Ada in high-intergrity systems.  The
document identifies language features and combinations of features which
are most likely to complicate reasoning about the behaviour of Ada
programs; clearly this includes behaviour which might be erroneous.

At a more rigorous level, the SPARK language makes it possible to
construct programs which can be shown, prior to execution, to be free
from _any_ erroneous behaviour; this includes proving that the program
will not raise any predefined exceptions. 

Peter


-- 
---------------------------------------------------------------------------   
      __         Peter Amey, Product Manager
        )                    Praxis Critical Systems Ltd
       /                     20, Manvers Street, Bath, BA1 1PX
      / 0        Tel: +44 (0)1225 466991
     (_/         Fax: +44 (0)1225 469006
                 http://www.praxis-cs.co.uk/

--------------------------------------------------------------------------

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

[Vladimir Olensky]

Markus Kuhn wrote in message <7jo1d2$kno$1@pegasus.csx.cam.ac.uk>...
>Peter Amey <pna@praxis-cs.co.uk> writes:
>|> There certainly has been some work in this area.  At a pragmatic level
>|> there is the Ada HRG which has produced (under auspices of ISO) a
>|> guidance document on the use of Ada in high-intergrity systems.  The
>|> document identifies language features and combinations of features which
>|> are most likely to complicate reasoning about the behaviour of Ada
>|> programs; clearly this includes behaviour which might be erroneous.
>
>This document is freely available from
>
>  http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf
>


I looked through it and found it  very useful.

I was talking exactly about such kind of document (may be more comprehensive
though).

What is interesting it was published only 30 days ago (99-05-11).

It itself contains a lot of useful references.

What is good that it is an official Ada ISO document.

This document (and it's home)  should  be referenced from each Ada related
site.


Regards,

Vladimir Olensky

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

[Robert Dewar]

In article <929128919.557.95@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> I was talking exactly about such kind of document (may be more
> comprehensive though).

I am really not sure how this document could be more
comprehensive. Perhaps you miss the point, which is that
it is VERY specifically aimed at safety critical programming
in Ada, and is not for a moment a general style document.

In fact safety-critical programming is a rather specialized
area, so although I agree this document is very valuable,
I am not quite sure I share your view of its universal
applicability!



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

[JP Thornley]

In article: <7jsdkf$v3p$1@nnrp1.deja.com>  Robert Dewar 
<robert_dewar@my-deja.com> writes:

(with reference to the HRG Guidance)

> it is VERY specifically aimed at safety critical programming
> in Ada

Definitely not so - and if this becomes the accepted idea then a number 
of programmers are likely to ignore a very useful document. 
(Particularly if they take Robert's other comments to mean that 
safety-critical programming is an arcane art with little connection to 
the 'real-world').

The Guide is _aimed at_ producers of high integrity software, where the 
software supplier is (usually) required to demonstrate the integrity of 
the software to a third party (who may be a certification authority or, 
perhaps, a knowledgeable customer).

It is _useful to_ anyone who wants to make consistent use of one or more 
of the verification methods referenced in the Guide as it helps them to 
avoid language features that are difficult to verify by the chosen 
techniques. (All of the usual techniques are included in the Guide.)

In another message, "Vladimir Olensky" <vladimir_olensky@yahoo.com> 
wrote:
> What is interesting it was published only 30 days ago (99-05-11).

Yes, but that is simply the latest in a long line of minor revisions. 
The document has been largely unchanged for over a year - an earlier 
draft was published in Ada Letters last year (may have been around 
April/May) and there are some detailed changes from that version, but 
nothing major.

Phil Thornley

-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
|                      phil.thornley@acm.org                           |
------------------------------------------------------------------------

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

[Matthew Heaney]

On 13 Jun 1999 01:10, "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:

> To my point of view this document (N359) is extremely valuable and
> every self-respected engineer who has something to do with Ada (or
> intends to do) should have it at hand.

I haven't read the document, so maybe it's time.  Can someone post a
full citation, with instructions about how to get a copy?

Thanks,
Matt

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

[Vladimir Olensky]

Robert Dewar wrote in message <7jsdkf$v3p$1@nnrp1.deja.com>...
>In article <929128919.557.95@news.remarQ.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>> I was talking exactly about such kind of document (may be more
>> comprehensive though).
>
>I am really not sure how this document could be more
>comprehensive. Perhaps you miss the point, which is that
>it is VERY specifically aimed at safety critical programming
>in Ada, and is not for a moment a general style document.
>
>In fact safety-critical programming is a rather specialized
>area, so although I agree this document is very valuable,
>I am not quite sure I share your view of its universal
>applicability!
>


Please read more carefully other people posts prior to making claims that
someone has missed the point.
Many people have heard this more than once :-(
It seems that we have here one person who thinks that he never misses the
point :-)
Let's join the club :-)

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.
To my  point of view this document (N359) is  extremely valuable and every
self-respected engineer who has something to do with Ada (or intends to do)
should have it at hand.
This document could be considered as general guidance for writing reliable
software in Ada (and not only in Ada).

Unfortunately N350 which is a draft of N359  has not been advertised across
Ada WEB sites so it seems that not too many Ada people were aware of it.
Otherwise I would get Markus Kuhn  response with reference to N359 from
someone else next after I mentioned about "such kind of document".

I could not  agree  that writing reliable software is specialized area.
Just contrary I think that this is universal area.

Remember how many people are complaining that something is unreliable for
example - Windows NT.
But a lot of people just forget that any OS should protect itself.  If some
application is doing something wrong WinNT just kills it (and no  problems
any more).
So complains should be about badly (or not very professional)  written
applications.
So much mentioned "blue dreaded screen" is usually cased (in 99.9%)  by
third party device drivers or services that have access to protected  OS
resources and are doing something wrong.
So writing reliable software is indeed universal area and this means that
person/team that is doing something  should know all things that can cause
unpredictable behavior (in Programming Language and used OS).
This also means that they should know as much as possible about how "not to
do" in order to provide reliability.
This is universal law as well.
In order not to make mistakes one should learn other's mistakes or summary
of such experience.
In real life this is of course a little bit  different . Some people  are
not even able to learn their own mistakes.



Regards,

Vladimir Olensky

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

[Vladimir Olensky]

JP Thornley wrote in message <489533776wnr@diphi.demon.co.uk>...
>In article: <7jsdkf$v3p$1@nnrp1.deja.com>  Robert Dewar
><robert_dewar@my-deja.com> writes:
>
>(with reference to the HRG Guidance)
>
>> it is VERY specifically aimed at safety critical programming
>> in Ada
>
>Definitely not so - and if this becomes the accepted idea then a number
>of programmers are likely to ignore a very useful document.
>(Particularly if they take Robert's other comments to mean that
>safety-critical programming is an arcane art with little connection to
>the 'real-world').
>
>The Guide is _aimed at_ producers of high integrity software, where the
>software supplier is (usually) required to demonstrate the integrity of
>the software to a third party (who may be a certification authority or,
>perhaps, a knowledgeable customer).
>
>It is _useful to_ anyone who wants to make consistent use of one or more
>of the verification methods referenced in the Guide as it helps them to
>avoid language features that are difficult to verify by the chosen
>techniques. (All of the usual techniques are included in the Guide.)


Suport all said above.

>
>In another message, "Vladimir Olensky" <vladimir_olensky@yahoo.com>
>wrote:
>> What is interesting it was published only 30 days ago (99-05-11).
>
>Yes, but that is simply the latest in a long line of minor revisions.
>The document has been largely unchanged for over a year - an earlier
>draft was published in Ada Letters last year (may have been around
>April/May) and there are some detailed changes from that version, but
>nothing major.


I've seen N350 also.
To my point of view one of the  problems with it was that it  was not widely
advertised.
The other thing is an erroneous idea that writing reliable software  is VERY
specialized area.

Regards,

Vladimir Olensky

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

[Robert Dewar]

In article <929221844.567.59@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>
> Robert Dewar wrote in message <7jsdkf$v3p$1@nnrp1.deja.com>...
> >In article <929128919.557.95@news.remarQ.com>,
> >  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
> >> I was talking exactly about such kind of document (may be
more
> >> comprehensive though).
> >
> >I am really not sure how this document could be more
> >comprehensive. Perhaps you miss the point, which is that
> >it is VERY specifically aimed at safety critical programming
> >in Ada, and is not for a moment a general style document.
> >
> >In fact safety-critical programming is a rather specialized
> >area, so although I agree this document is very valuable,
> >I am not quite sure I share your view of its universal
> >applicability!
>

> Please read more carefully other people posts prior to making
> claims that
> someone has missed the point.
> Many people have heard this more than once :-(
> It seems that we have here one person who thinks that he never
> misses the point :-)
> Let's join the club :-)
>
> 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.

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

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.

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.

My point of view is that this document is an excellent AND
complete summary statement of what is needed for high integrity
programming in Ada.






Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

[Robert Dewar]

In article <929221844.567.59@news.remarQ.com>,
  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:

> Unfortunately N350 which is a draft of N359  has not been
> advertised across Ada WEB sites so it seems that not too many
> Ada people were aware of it. Otherwise I would get Markus Kuhn
> response with reference to N359 from someone else next after I
> mentioned about "such kind of document".

I think it was publicized at an appropriate level. This was
basically work in progress by one of the Rapporteur Groups
of WG9, and it is not appropriate to put it out for any kind
of official public comment before it has been submitted to
WG9. Most certainly the HRG has been quite open in the way
it proceeds, at quite an appropriate level, but posting drafts
to CLA is certainly NOT appropriate in my view.

Each country decides for itself the extent to which it will
subject such ISO documents to general review. In the case of
the USA, there were several experts in the area of high
integrity programming participating in the HRG, and I think
there was adequate input.

> I could not  agree  that writing reliable software is
> specialized area.

No, but writing high integrity software *IS* more specialized.

If you decide that

  reliable = high integrity

then you reduce the discussion of special concerns of high
integrity programming to general discussions of good style
for writing reliable Ada programs, and I think this is far
too much of a dilution of the intentions here.

> Just contrary I think that this is universal area.

Concern for reliability is universal.
Use of restricted subsets of Ada for high integrity programs
is NOT a universal area at all.

> Remember how many people are complaining that something is
> unreliable for
> example - Windows NT.

No one for a moment would claim OR EXPECT Windows NT to qualify
as high integrity software, and indeed it would be out of the
question for high integrity software to be based on the use
of NT in my view. Indeed only a VERY simple operating executive
could reach the level of being certified as high integrity
software.

Remember that one important aspect of high integrity software
is that in general it must be verified at the object machine
instruction level (because we also do not have trusted Ada
compilers, and indeed we do not know how to build a trusted
Ada compiler). To verify a program like NT at this level (with
its 5-10 million lines of code) is out of the question at our
current level of technology.

A typical productivity level for high integrity code is,
according to several people in the field (this is not from
my personal experience) of the order of 1-2 machine instructions
per person day.

That means that the 10 million lines of code in NT might take
10 million person days = 50,000 person years = a very long
time to get a product out (and perhaps 10 billion dollars).
Quite a bit even for Microsoft, but of course such calculations
are bogus, since these things don't scale, and we just don't
know how to build high integrity programs this large (look at
Dave Parnas' statements concering SDI, this was a substantial
part of his concerns about the credibility of the software
component of this system as originally proposed).

Now please do not misunderstand, I think everyone should read
the HRG report (I would assume that any Ada professional should
always read all official documents from ISO WG9), and there may
be useful things to be learned from the document that have wider
applicability.

But I think you have to be careful not to go in the direction
that Vladimir does, confusing the specific focus of this
document with the generalized need for realiability.

Remember that the WHOLE of the Ada language was carefully
designed to be compatible with the goal of writing highly
reliable programs. There is almost NO feature mentioned in
the RM that does not have a legitimate use in reliable Ada
programs.

I am worried that people will start looking at the
recommendations in the HRG report for restricting the
use of Ada for high integrity programming (a realistic and
necessary step) and make the mistake of thinking that this
means that these features are generally unsafe if your goal
is to write reliable programs.

Robert Dewar





Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

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

[Vladimir Olensky]

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

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

[Vladimir Olensky]

Robert Dewar wrote in message <7jvc2j$o68$1@nnrp1.deja.com>...
>In article <929221844.567.59@news.remarQ.com>,
>  "Vladimir Olensky" <vladimir_olensky@yahoo.com> wrote:
>
>No, but writing high integrity software *IS* more specialized.
>
>If you decide that
>
>  reliable = high integrity
>
>then you reduce the discussion of special concerns of high
>integrity programming to general discussions of good style
>for writing reliable Ada programs, and I think this is far
>too much of a dilution of the intentions here.
>
>> Just contrary I think that this is universal area.
>
>Concern for reliability is universal.
>Use of restricted subsets of Ada for high integrity programs
>is NOT a universal area at all.


************
I am not trying to set the rule that "reliable = high integrity".
There are a lot of intermediate levels between them.
N359 just helps to choose appropriate approach for particular design goal.
Again I would like to stress that there should not be a black and white
approaches.
*************
>> Remember how many people are complaining that something is
>> unreliable for
>> example - Windows NT.
>
>No one for a moment would claim OR EXPECT Windows NT to qualify
>as high integrity software, and indeed it would be out of the
>question for high integrity software to be based on the use
>of NT in my view. Indeed only a VERY simple operating executive
>could reach the level of being certified as high integrity
>software.
>
>Remember that one important aspect of high integrity software
>is that in general it must be verified at the object machine
>instruction level (because we also do not have trusted Ada
>compilers, and indeed we do not know how to build a trusted
>Ada compiler). To verify a program like NT at this level (with
>its 5-10 million lines of code) is out of the question at our
>current level of technology.
>
>A typical productivity level for high integrity code is,
>according to several people in the field (this is not from
>my personal experience) of the order of 1-2 machine instructions
>per person day.
>
>That means that the 10 million lines of code in NT might take
>10 million person days = 50,000 person years = a very long
>time to get a product out (and perhaps 10 billion dollars).
>Quite a bit even for Microsoft, but of course such calculations
>are bogus, since these things don't scale, and we just don't
>know how to build high integrity programs this large (look at
>Dave Parnas' statements concering SDI, this was a substantial
>part of his concerns about the credibility of the software
>component of this system as originally proposed).


***************
Here I was just  saying that in many cases some people blame OS instead of
blaming badly written applications (especially in OS flames).  As for me I
am using WinNT as an equipment  control center that runs (7 days 24 hours) a
dozen of applications controlling different pieces of equipment along with
number of "run and stop" applications.  It never crashed during last three
years ( it was put into operation three years ago).
**********

>Now please do not misunderstand, I think everyone should read
>the HRG report (I would assume that any Ada professional should
>always read all official documents from ISO WG9), and there may
>be useful things to be learned from the document that have wider
>applicability.
>
>But I think you have to be careful not to go in the direction
>that Vladimir does, confusing the specific focus of this
>document with the generalized need for realiability.

**********
Direction is to fully understand all strong and weak sides and to chose
consciously what is needed for particular purpose.

************

>Remember that the WHOLE of the Ada language was carefully
>designed to be compatible with the goal of writing highly
>reliable programs. There is almost NO feature mentioned in
>the RM that does not have a legitimate use in reliable Ada
>programs.


*******
I mentioned once about some kind of trap here. Some people may have wrong im
pression that Ada is so reliable itself that there is no need of careful
consideration of potentially unsafe features. Sometimes even safe features
can cause problems.
I have an impression that developers of Arian 5 were caught in such kind of
trap and as result they did not do what was needed.
***********


>I am worried that people will start looking at the
>recommendations in the HRG report for restricting the
>use of Ada for high integrity programming (a realistic and
>necessary step) and make the mistake of thinking that this
>means that these features are generally unsafe if your goal
>is to write reliable programs.

There are people and people.
Some take any written paper as direct instructions.
Others understand that it is just summary of other people knowledge  and
experience.
Such kind of documents could help to safely use some potentially unsafe
features.



Regards,

Vladimir Olensky

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

[Vladimir Olensky]

Matthew Heaney wrote in message ...
>On 13 Jun 1999 01:10, "Vladimir Olensky" <vladimir_olensky@yahoo.com>
wrote:
>
>> To my point of view this document (N359) is extremely valuable and
>> every self-respected engineer who has something to do with Ada (or
>> intends to do) should have it at hand.
>
>I haven't read the document, so maybe it's time.  Can someone post a
>full citation, with instructions about how to get a copy?


N359
ISO/IEC DTR 15942. Programming Languages -- Guide for the Use of the Ada
Programming Language in High Integrity Systems

This document is freely available from

  http://www.dkuug.dk/JTC1/SC22/WG9/n359.pdf

This reference was originally posted by Markus Kuhn.

Regards,

Vladimir Olensky

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

[swhalen]

Robert Dewar (robert_dewar@my-deja.com) wrote:
: 
: 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...
[snip]
: 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.

Many excellent points and much useful information in this thread.

I agree with those who believe that the 359 document should be
"pushed" more widely in the Ada community.

I take your point that over emphasis of "high integrity" processes
like those described in the 359 document can lead to unintended
consequences or needless expense or even failed projects.

However, in many systems there are portions of the system that MUST be
more reliable and robust and trusted than the rest of the system. The
techniques and processes described in the "high integrity" document
may be entirely appropriate for a small portion of a larger system.

By applying the "high integrity" processes and $$$ to a small portion
of a larger system, you can greatly increase overall reliablity and
improve the value of the system, even if the system is not in one of
the categories of systems we typically think of as requiring "high
integrity".

Steve

-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: Ada safety road

[Franco Mazzanti]

Keith Thompson wrote:
> 
> kilgallen@eisner.decus.org (Larry Kilgallen) writes:
> > In article <928703068.617.98@news.remarQ.com>, "Vladimir Olensky" <vladimir_olensky@yahoo.com> writes:
> > > But I see one problem here.  All this information is scattered
> > > around RM.
> >
> > In order to be definitive, the RM should not duplicate information in
> > various locations, and thus cannot be in the ideal exposition format
> > for all purposes.
> 
> The RM already has several "informative" annexes, which are not
> strictly part of the standard.  Annexes K (attributes) and L (pragmas)
> are particularly useful, even though (or rather *because*) they
> duplicate information scattered around the RM.  An informative annex
> listing all occurrences of erroneous execution and bounded errors
> would have been useful.
> 
> As I was writing this, I realized we already have the next best thing.
> The entry for "erroneous" in the RM's index refers to all the places
> in the RM where the term is used; likewise for "bounded error".
> 
> This brings up a pet peeve of mine: the word "erroneous" was a poor
> choice of terminology.  It's an existing English word with a
> well-defined meaning.  When I use the word in an Ada context, I very
> often have to explain the Ada-specific meaning.  It also fails to make
> it clear that it's the execution of a construct that's erroneous, not
> the construct itself.  Norman Cohen, in his book "Ada as a Second
> Language", uses the phrase "unbounded error", which is much clearer.
> Another good term is "undefined behavior", used by the C and C++
> standards for (essentially) the same concept.
> 
...

Some time ago I did that job of collecting from all the RM all this
kind of information related to erroneous executions. It took a long
time, 
and it has been a much harder job rather than what initially expected,
but in the end I think I succeded in getting the whole picture.
If anybody is interested, the report can downloaded by anonymous ftp
from:
  ftp://rep1.iei.pi.cnr.it/pub/mazzanti/publications/EEG.ps
(it is an IEI report)
Some printed copies are also available under request.

It is almost two years old, so some details concerning new or 
recently revised Ada Commentaries may be absent.

Any comments on that report are still welcome.

   Franco Mazzanti   
   Istituto di Elaborazione della Informazione
   Via S.Maria 46, 56126 Pisa, ITALY
   Tel: +39050-593447/593400, Fax: +39-50-554342
   e-mail: mazzanti@iei.pi.cnr.it
------------------------------------------------------------

Re: Ada safety road

[Franco Mazzanti]

> Some time ago I did that job of collecting from all the RM all this
> kind of information related to erroneous executions. It took a long
> time,
> and it has been a much harder job rather than what initially expected,
> but in the end I think I succeded in getting the whole picture.
> If anybody is interested, the report can downloaded by anonymous ftp
> from:
>   ftp://rep1.iei.pi.cnr.it/pub/mazzanti/publications/EEG.ps
> (it is an IEI report)
> 

Thanks to Jim Hopper, now a pdf version of the same report is also
available:
  ftp://rep1.iei.pi.cnr.it/pub/mazzanti/publications/EEG.pdf

Franco Mazzanti

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

[William Dale]

JP Thornley wrote:
> 
> In article: <7jsdkf$v3p$1@nnrp1.deja.com>  Robert Dewar
> <robert_dewar@my-deja.com> writes:
> 
> (with reference to the HRG Guidance)
> 
> > it is VERY specifically aimed at safety critical programming
> > in Ada
> 
> Definitely not so - and if this becomes the accepted idea then a number
> of programmers are likely to ignore a very useful document.
> (Particularly if they take Robert's other comments to mean that
> safety-critical programming is an arcane art with little connection to
> the 'real-world').
> 
> The Guide is _aimed at_ producers of high integrity software, where the
> software supplier is (usually) required to demonstrate the integrity of
> the software to a third party (who may be a certification authority or,
> perhaps, a knowledgeable customer).
> 
> It is _useful to_ anyone who wants to make consistent use of one or more
> of the verification methods referenced in the Guide as it helps them to
> avoid language features that are difficult to verify by the chosen
> techniques. (All of the usual techniques are included in the Guide.)
> 

I hope the document covers the system trade-offs of going through
such rigorous and costly certifications when a simple hardware addition 
would make the system safe.  

Too often the software effort is forced to shoulder the entire 
burden of system safety.  Gutting language features to make software 
certifiable is often coupled with irrational fear of new features 
and technology. 

Many times it still does not make for a "safe" system. When safety 
certified applications sit on top of untested operating systems 
and amidst other COTS applications disaster is possible, 
maybe probible. 

[snip]
-- 

"The difference between hardware and software is that the more you play
with hardware, the more likely you are to break it, but the more you
play with software the more likely you are to FIX it."

Bill Dale 
LMMS
mailto:william.dale.jr@lmco.com
mailto:N2RHV@amsat.org

Re: Ada safety road

[Vladimir Olensky]

Franco Mazzanti wrote in message <37660F7A.870D2A3A@tin.it>...
>
>> Some time ago I did that job of collecting from all the RM all this
>> kind of information related to erroneous executions. It took a long
>> time,
>> and it has been a much harder job rather than what initially expected,
>> but in the end I think I succeded in getting the whole picture.
>> If anybody is interested, the report can downloaded by anonymous ftp
>> from:
>>   ftp://rep1.iei.pi.cnr.it/pub/mazzanti/publications/EEG.ps
>> (it is an IEI report)
>>
>
>Thanks to Jim Hopper, now a pdf version of the same report is also
>available:
>  ftp://rep1.iei.pi.cnr.it/pub/mazzanti/publications/EEG.pdf
>
>Franco Mazzanti


I looked through your report  and I was really impressed.
This is what I had in mind (and may be even more) talking about such kind of
document  in my previous posts.
This is very comprehensive document and it is really Ada safety roadmap.
Your report and ISO N359 document  can provide great help to those using Ada
in making their software more reliable.

Best regards,
Vladimir Olensky

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

[JP Thornley]

In article: <37682F64.59E2@lmco.com>  William Dale 
<william.dale.jr@lmco.com> writes:

[with reference to the HRG Guidance)
> I hope the document covers the system trade-offs of going through
> such rigorous and costly certifications when a simple hardware addition 
> would make the system safe.  

Well, since I said that:
"The Guide is _aimed at_ producers of high integrity software, where the
 software supplier is (usually) required to demonstrate the integrity of
 the software",
it is difficult to see why anyone would expect to see discussions of 
system safety and the choice of hardware solutions in the Guide.

> 
> Too often the software effort is forced to shoulder the entire 
> burden of system safety.  Gutting language features to make software 
> certifiable is often coupled with irrational fear of new features 
> and technology. 

The Guide makes no recommendations based on the newness of language 
features. What it does is to analyse the interaction between the 
verification techniques used for software and the features of Ada 95, 
pointing out those language features that will make each technique 
either difficult or impossible to apply.

> 
> Many times it still does not make for a "safe" system. When safety 
> certified applications sit on top of untested operating systems 
> and amidst other COTS applications disaster is possible, 
> maybe probible. 

But surely no application can be certified other than as part of 
a complete system - which must include the operating system/other COTS 
components.

Safety is an attribute of a system, never of software.

> 
> Bill Dale 
> 
> 

Phil Thornley
-- 
------------------------------------------------------------------------
| JP Thornley    EMail jpt@diphi.demon.co.uk                           |
|                      phil.thornley@acm.org                           |
------------------------------------------------------------------------

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

[Robert A Duff]

William Dale <william.dale.jr@lmco.com> writes:

>...  Gutting language features to make software 
> certifiable is often coupled with irrational fear of new features 
> and technology. 

... and sometimes with a rational fear of new features and technology.  ;-)

> "The difference between hardware and software is that the more you play
> with hardware, the more likely you are to break it, but the more you
> play with software the more likely you are to FIX it."

Hmm.  Unfortunately, that's not always true.

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.