Re: Unchecked_Deallocation subtleties

[Nick Roberts <nickroberts@blueyonder.co.uk>]

On Wed, 9 Apr 2003 09:10:21 +0000 (UTC), Piotr Zgorecki 
<pioter@terramail.CUTTHIS.pl> wrote:

> I have a problem with interpretation of ARM 13.11.2(8):
>
> "Free(X), when X is already equal to null, has no effect."
>
> I'm looking at an implementation which will call user-defined
> Deallocate, whether X is null or not. Is it correct?

I believe this implementation is 'right'. It is certainly right if the 
module which contains the user-defined deallocation also chooses the 
representation(s) of a null pointer. Generally, is will be for the user- 
defined Deallocate to test if the access value is null, and do nothing (as 
the RM specifies) if it is.

> I would suppose 'has no effect' means that Deallocate
> shouldn't be called, because it can potentially have
> side effects.

To my mind it simply means that the user-defined implementation of 
Deallocate should behave in the way required by the RM if it is intended to 
obey the standard (for example being part of a product that will be sold on 
the understanding that it conforms to the standard).

Do not be confused. The RM itself states that conforming implementations of 
Ada are permitted to have modes which do not conform. Furthermore, only a 
maniacal pedant would prefer an implementation which conforms over one 
which does exactly what the user actually requires (for a particular 
application).

Regardless of whether it conforms to the standard or not, the only thing 
that a user-defined Deallocate -- or indeed any other implementation of a 
language feature -- really /should/ do is whatever is specified and 
required. If conforming to the standard is specified, an implementation 
should do what the RM says; on the other hand, if ringing a bell every time 
Deallocate is called is specified, then that is what the implementation 
should do.

> Life would be easier if ARM had 'no effect' stuff strictly defined.

I think the RM often tries to be too exact about a lot of things, and is 
too vague (as a result of overcomplexity) about some things.

A programming language is a tool to do a job; it is not a religion or a law 
system. It is very good to define (and enforce) a standard in a way that 
enables real-life programs in practice to be ported very easily between 
implementations, but it is a waste of effort to try to circumscribe 
implementations any further than that. Presumably the Ada compiler that 
NASA uses for the Space Shuttle's flight software will not (and should not) 
be quite the same as the Ada compiler I use for my train set controller.

Just my $0.02091 worth (inflation adjusted).

-- 
Nick Roberts
Jabber: debater@charente.de [ICQ: 159718630]