Re: A Bug in VAX Ada (ACCVIO)

[firth@sei.cmu.edu (Robert Firth)]

In article <124000008@inmet> ron@inmet.UUCP writes:

>Over the last few years, I've encountered various bugs with the VAX Ada
>compiler's handling of access types.  The simplest (and my personal
>favorite) example is that Unchecked_Deallocation(null) raises
>Program_Error.  This is my favorite because the only concrete thing
>that the LRM has to say about Unchecked_Deallocation is that after any
>call to Unchecked_Deallocation(x), x is null.

Sorry, not so.  RM 13.10.1 (b) says explicitly

	" FREE(X), when X is already equal to null, has no effect"

(where FREE is an instantiation of UNCHECKED_DEALLOCATION)

We discussed this point, and decided that it was appropriate for
FREE to take very weak preconditions.  Note also that Ada doesn't
require X to be the only variable whose value designates the
deallocated object, merely that you don't subsequently use such
a value to access the object.

We also decided to say most of this explicitly, to avoid the kind of
oversight that the above compiler seems to have made.  This might
seem needlessly pedantic (after all, who would do it any other way?),
but I'm glad we were mistrustful.

I can recall another important issue where we DID trust the
implementors.  The question was raised at one DR meeting: should
we say explicitly that one task doing input from a slow device
does not cause the whole program to block?  The response was almost
universal stupified disbelief that any implementor would ever be
so incompetent as to do it that way.  Sigh!