Unchecked_Deallocation subtleties

Unchecked_Deallocation subtleties

[Piotr Zgorecki]

Hi,

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 would suppose
'has no effect' means that Deallocate shouldn't be called, because it
can potentially have side effects. Life would be easier if ARM had 'no
effect' stuff strictly defined.

Regards,
Piotr Zgorecki

Re: Unchecked_Deallocation subtleties

[Samuel Tardieu]

>>>>> "Piotr" == Piotr Zgorecki <pioter@terramail.CUTTHIS.pl> writes:

Piotr> "Free(X), when X is already equal to null, has no effect."

Piotr> I'm looking at an implementation which will call user-defined
Piotr> Deallocate, whether X is null or not. Is it correct? I would
Piotr> suppose 'has no effect' means that Deallocate shouldn't be
Piotr> called, because it can potentially have side effects. Life
Piotr> would be easier if ARM had 'no effect' stuff strictly defined.

"no effect" means "no user observable effect". Just as if you didn't
call "Free(X)". If "Deallocate" may have side effects, it should not
be called.

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Unchecked_Deallocation subtleties

[Marin David Condic]

Samuel Tardieu <sam@rfc1149.net> wrote in message
news:87smssj94u.fsf@inf.enst.fr...
>
> "no effect" means "no user observable effect". Just as if you didn't
> call "Free(X)". If "Deallocate" may have side effects, it should not
> be called.
>
No side effect other than possibly execution time. I don't believe the ARM
considers execution time to to be a factor in determining if there is "no
effect" - but obviously, in some applications, that might be an issue.

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Re: Unchecked_Deallocation subtleties

[Samuel Tardieu]

>>>>> "Marin" == Marin David Condic <mcondic.auntie.spam@acm.org> writes:

Marin> No side effect other than possibly execution time. I don't
Marin> believe the ARM considers execution time to to be a factor in
Marin> determining if there is "no effect" - but obviously, in some
Marin> applications, that might be an issue.

I agree, but the RM deliberately ignores such a factor. Otherwise, no
function would ever be Pure in the RM sense, as the omission of the
call would never yield the same "result".

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Unchecked_Deallocation subtleties

[Marin David Condic]

Samuel Tardieu <sam@rfc1149.net> wrote in message
news:873ckr979l.fsf@inf.enst.fr...
>
> I agree, but the RM deliberately ignores such a factor. Otherwise, no
> function would ever be Pure in the RM sense, as the omission of the
> call would never yield the same "result".
>
Obviously, as a language standard, it must for the most part ignore time. It
can't account for how something gets implemented, so trying to address time
becomes problematic. In probably 99.9% of the applications, time doesn't
matter, so if a function takes more or less time dealing with the
off-nominal case, nobody much cares. But put that call in a selective wait
with a delay alternative and suddenly you might see different program
behavior if the off-nominal case changes the timing.

I just brought it up as a reminder that "no effect" from the ARM perspective
is not equivalent to "no observable difference in the real world". The ARM
concern is that there be no semantic effect. A call to a deallocate routine
with a null pointer might cause the rectal extraction of several flying
monkeys, but so long as the program continues to compute what the ARM
expects, its happy. :-)

MDC
--
======================================================================
Marin David Condic
I work for: http://www.belcan.com/
My project is: http://www.jsf.mil/

Send Replies To: m c o n d i c @ a c m . o r g

    "Going cold turkey isn't as delicious as it sounds."
        -- H. Simpson
======================================================================

Re: Unchecked_Deallocation subtleties

[Warren W. Gay VE3WWG]

Marin David Condic wrote:
> Samuel Tardieu <sam@rfc1149.net> wrote in message
> news:87smssj94u.fsf@inf.enst.fr...
> 
>>"no effect" means "no user observable effect". Just as if you didn't
>>call "Free(X)". If "Deallocate" may have side effects, it should not
>>be called.
>>
> 
> No side effect other than possibly execution time. I don't believe the ARM
> considers execution time to to be a factor in determining if there is "no
> effect" - but obviously, in some applications, that might be an issue.
> 
> MDC
> --
> ======================================================================
> Marin David Condic
> I work for: http://www.belcan.com/

I have always believed that this type of "permissiveness" is bad. If
the caller knew in advance that there was nothing to free, then Free(X)
would never be called in the first place. To me, this (when X is null)
should raise an exception since it represents an unintended operation or
state of the access type.

It appears that a concession has been made to lazy programmers so that
they can avoid the necessary if statements, such as:

if X /= null then
    Free(X);
end if;

This issue must have been hotly debated at one time or another (and
perhaps re-occuringly so).  Of course, you can always insist on a
different behaviour, by including a wrapper routine in your application
(but I still would have preferred the other "default").

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Unchecked_Deallocation subtleties

[Nick Roberts]

On Wed, 09 Apr 2003 12:54:06 -0400, Warren W. Gay VE3WWG <ve3wwg@cogeco.ca> 
wrote:

[that an instance of Unchecked_Deallocation (e.g. 'Free') permits
the access value passed to it to be null]
>
> I have always believed that this type of "permissiveness" is
> bad. If the caller knew in advance that there was nothing to
> free, then Free(X) would never be called in the first place.
> To me, this (when X is null) should raise an exception since
> it represents an unintended operation or state of the access
> type [value?].
>
> It appears that a concession has been made to lazy
> programmers so that they can avoid the necessary if
> statements, such as:
>
> if X /= null then
> Free(X);
> end if;

To be fair to the designers of Ada (83), I suspect that upon deep 
deliberation they found that the behaviour specified (a null value is 
permitted, and does nothing) could not sensibly be avoided. I'll try to 
explain why.

Consider the following example skeleton piece of code:

   declare
      X: Some_Access_Type;
   begin
      ...         -- [1]
      Y := X.all; -- [2] last use of X
      ...         -- [3]
      Free(X);    -- [4]
   end;

Although it may be that no compiler would (or even could) do so in 
practice, other rules in the ARM made it theoretically possible for the 
implementation to automatically reclaim the storage occupied by whatever X 
pointed to (assuming no other access value pointed to it) at any point in 
the elided code section [3]. If this were to occur, the implementation 
would be within its rights to set X to null at the same time. Thus X could 
legitimately be null by the time it gets to [4]. In practice this would be 
found to be a general situation.

So, not permitting Free to simply ignore a null value would theoretically 
have condemned every and any call to Free to have the explicit test for a 
null value, and I'm sure that the Ada ('Green') design team didn't fancy 
that idea.

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

Re: Unchecked_Deallocation subtleties

[Samuel Tardieu]

>>>>> "Nick" == Nick Roberts <nickroberts@blueyonder.co.uk> writes:

Nick> Consider the following example skeleton piece of code:

Nick>    declare
Nick>       X: Some_Access_Type;
Nick>    begin
Nick>       ...  -- [1] Y := X.all; -- [2] last use of X ...  -- [3]
Nick>       Free(X); -- [4]
Nick>    end;

Nick> Although it may be that no compiler would (or even could) do so
Nick> in practice, other rules in the ARM made it theoretically
Nick> possible for the implementation to automatically reclaim the
Nick> storage occupied by whatever X pointed to (assuming no other
Nick> access value pointed to it) at any point in the elided code
Nick> section [3].

I would say that Free(X) is certainly a use of X, so the last use of X
is not in [2], it is in [4].

  Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Unchecked_Deallocation subtleties

[Nick Roberts]

On Wed, 09 Apr 2003 23:39:31 +0200, Samuel Tardieu <sam@rfc1149.net> wrote:

>>>>>> "Nick" == Nick Roberts <nickroberts@blueyonder.co.uk> writes:
>
> Nick> Consider the following example skeleton piece of code:
>
> Nick>    declare
> Nick>       X: Some_Access_Type;
> Nick>    begin
> Nick>       ...         -- [1]
> Nick>       Y := X.all; -- [2] last use of X
> Nick>       ...         -- [3]
> Nick>       Free(X);    -- [4]
> Nick>    end;
>
> Nick> Although it may be that no compiler would (or even could) do so
> Nick> in practice, other rules in the ARM made it theoretically
> Nick> possible for the implementation to automatically reclaim the
> Nick> storage occupied by whatever X pointed to (assuming no other
> Nick> access value pointed to it) at any point in the elided code
> Nick> section [3].
>
> I would say that Free(X) is certainly a use of X, so the last use of X
> is not in [2], it is in [4].

Hmmmm. Obviously you are right, Sam, on the face of it. Theoretically 
(there's that word again), a compiler could apply a special rule to an 
instance of Unchecked_Deallocation (that, for each call, the object pased 
to it is not considered to have been used), on the basis that this would 
never do any harm and might provide opportunities for earlier automatic 
storage reclamation. In practice I doubt any compiler has ever actually 
done this.

Furthermore (on going back to the manuals), I note that Ada allows the 
Controlled pragma to be applied to an access type to instruct the compiler 
not to perform automatic storage reclamation, although neither the Ada 83 
nor the Ada 95 standards made it requisite to apply this pragma to an 
access type for which Unchecked_Deallocation is also used.

So, I'm trying to point out my guess as to the thought processes of the Ada 
83 (Green) design team, despite the fact that it all turned out to be a bit 
theoretical.

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

Re: Unchecked_Deallocation subtleties

[Robert Spooner]

Nick Roberts wrote:
> 
> Hmmmm. Obviously you are right, Sam, on the face of it. Theoretically 
> (there's that word again)...

Wasn't it James Thurber who said, "When people say 'Theoretically' they 
mean 'not actually'" a number of years ago?  :)  He had a way of getting 
to the essence of things using humor.

Bob
-- 
                             Robert L. Spooner
                      Registered Professional Engineer
                        Associate Research Engineer
                   Intelligent Control Systems Department

          Applied Research Laboratory        Phone: (814) 863-4120
          The Pennsylvania State University  FAX:   (814) 863-7841
          P. O. Box 30
          State College, PA 16804-0030       rls19@psu.edu

Re: Unchecked_Deallocation subtleties

[Warren W. Gay VE3WWG]

Nick Roberts wrote:
> On Wed, 09 Apr 2003 23:39:31 +0200, Samuel Tardieu <sam@rfc1149.net> wrote:
> 
>>>>>>> "Nick" == Nick Roberts <nickroberts@blueyonder.co.uk> writes:
>>>>>>
>>
>> Nick> Consider the following example skeleton piece of code:
>>
>> Nick>    declare
>> Nick>       X: Some_Access_Type;
>> Nick>    begin
>> Nick>       ...         -- [1]
>> Nick>       Y := X.all; -- [2] last use of X
>> Nick>       ...         -- [3]
>> Nick>       Free(X);    -- [4]
>> Nick>    end;
>>
>> Nick> Although it may be that no compiler would (or even could) do so
>> Nick> in practice, other rules in the ARM made it theoretically
>> Nick> possible for the implementation to automatically reclaim the
>> Nick> storage occupied by whatever X pointed to (assuming no other
>> Nick> access value pointed to it) at any point in the elided code
>> Nick> section [3].
>>
>> I would say that Free(X) is certainly a use of X, so the last use of X
>> is not in [2], it is in [4].
> 
> Hmmmm. Obviously you are right, Sam, on the face of it. Theoretically 
> (there's that word again), a compiler could apply a special rule to an 
> instance of Unchecked_Deallocation (that, for each call, the object 
> pased to it is not considered to have been used), on the basis that this 
> would never do any harm and might provide opportunities for earlier 
> automatic storage reclamation. In practice I doubt any compiler has ever 
> actually done this.

Maybe I am looking at this incorrectly, but the most obvious place
to do garbage collection here (if implemented) is at the end of
the declare/begin block.  At the "end" statement, there is no more
doubt that the value X is no longer in use ;-) , despite any
contortions that might be present in the code.

So if I were implementing garbage collection, the point of the "end"
statement would be where an effective "Free(X)" behind the scenes
would be implied, if necessary.

While the code executes within that block, there is no
need to fuss over whether X is being used or not.
In fact that would be rather difficult to predict when X
was no longer required if you have goto's and such
present.

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Unchecked_Deallocation subtleties

[Nick Roberts]

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]

Re: Unchecked_Deallocation subtleties

[Nick Roberts]

On Wed, 09 Apr 2003 20:50:34 +0100, Nick Roberts 
<nickroberts@blueyonder.co.uk> wrote:

>> 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.

To reiterate, please cancel this opinion!

I was either thinking of something else entirely or just inebriated.

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

Re: Unchecked_Deallocation subtleties

[chris.danx]

Nick Roberts wrote:

> I was either thinking of something else entirely or just inebriated.

or both ;)

Re: Unchecked_Deallocation subtleties

[Keith Thompson]

Nick Roberts <nickroberts@blueyonder.co.uk> writes:
[...]
> 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.

Why not?  If there's an Ada compiler of high enough quality to use for
the Space Shuttle's flight software, why shouldn't you use the same
compiler for your train set controller?

-- 
Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

Re: Unchecked_Deallocation subtleties

[Nick Roberts]

"Keith Thompson" <kst@cts.com> wrote in message
news:yecr8844pdh.fsf@king.cts.com...

> > 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.
>
> Why not?  If there's an Ada compiler of high enough quality to use for
> the Space Shuttle's flight software, why shouldn't you use the same
> compiler for your train set controller?

Well for one thing, Keith, it might be a little too expensive! I can just
imagine my budget for a hobby project:

Engine & 4 Coaches  ... ... ... ... ... ... $    100.00
Track with Bridge . ... ... ... ... ... ... $    100.00
Power Unit  ... ... ... ... ... ... ... ... $     30.00
Actuator .. ... ... ... ... ... ... ... ... $     20.00
Sensors x 6 ... ... ... ... ... ... ... ... $     60.00
SBC Fully Pop . ... ... ... ... ... ... ... $    200.00
Assorted Components ... ... ... ... ... ... $     50.00
Ada Compiler .. ... ... ... ... ... ... ... $ 20,000.00

But otherwise I concede your point: there's no fundamental reason why many
Ada compilers could not be used for either purpose.

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

Re: Unchecked_Deallocation subtleties

[Larry Kilgallen]

In article <yecr8844pdh.fsf@king.cts.com>, Keith Thompson <kst@cts.com> writes:
> Nick Roberts <nickroberts@blueyonder.co.uk> writes:
> [...]
>> 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.
> 
> Why not?  If there's an Ada compiler of high enough quality to use for
> the Space Shuttle's flight software, why shouldn't you use the same
> compiler for your train set controller?

Perhaps you have train set requirements to use a more modern
processor than the latest one vetted for the Space Shuttle.
Most of us, for instance, adopt a cavalier attitude of not
requiring radiation-hardened processors for a train set.

Re: Unchecked_Deallocation subtleties

[Jacob Sparre Andersen]

Larry Kilgallen wrote:

> Perhaps you have train set requirements to use a more modern
> processor than the latest one vetted for the Space Shuttle.
> Most of us, for instance, adopt a cavalier attitude of not
> requiring radiation-hardened processors for a train set.

But I have always wanted to run model trains in the CERN tunnels.  ;-)

Jacob
-- 
"Banning open source would have immediate, broad, and
  strongly negative impacts on the ability of many sensitive
  and security-focused DOD groups to protect themselves
  against cyberattacks"                        -- Mitre Corp.

Re: Unchecked_Deallocation subtleties

[AG]

"Jacob Sparre Andersen" <sparre@crs4.it> wrote in message
news:3E9BF76F.50608@crs4.it...
> Larry Kilgallen wrote:
>
> > Perhaps you have train set requirements to use a more modern
> > processor than the latest one vetted for the Space Shuttle.
> > Most of us, for instance, adopt a cavalier attitude of not
> > requiring radiation-hardened processors for a train set.
>
> But I have always wanted to run model trains in the CERN tunnels.  ;-)

Close to the speed of light too. So that the trains start radiating
going around the corners on their own :-)

Re: Unchecked_Deallocation subtleties

[Randy Brukardt]

Piotr Zgorecki wrote in message ...
>Hi,
>
>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 would suppose
>'has no effect' means that Deallocate shouldn't be called, because it
>can potentially have side effects. Life would be easier if ARM had 'no
>effect' stuff strictly defined.


The implementation is clearly wrong.

The only place that the standard ever talks about calling the storage
pool Deallocate is in 13.11.2(9). That paragraph starts with "Free(X),
when X is not already equal to null...". So, there is no justification
for calling Deallocate, or Finalize, or doing anything when X is not
null.

"no effect" here means just that -- no effect: nothing is called,
executed, etc. I do agree that that term is not formally defined, so
there is a bit of wiggle room for implementations, but calling arbitrary
routines because its convinient seems to be beyond any wiggle room.
Especially as it is easy to do it correctly.

That said, unless you can get a patch from a vendor (and that usually
means that you're a favored customer), you probably ought to work around
it - it does not seem hard to do so.

            Randy Brukardt

Re: Unchecked_Deallocation subtleties

[Nick Roberts]

On Wed, 9 Apr 2003 16:23:36 -0500, Randy Brukardt <randy@rrsoftware.com> 
wrote:

> ...
>
> The implementation is clearly wrong.
>
> The only place that the standard ever talks about calling the storage
> pool Deallocate is in 13.11.2(9). That paragraph starts with "Free(X),
> when X is not already equal to null...". So, there is no justification
> for calling Deallocate, or Finalize, or doing anything when X is not
> null.
>
> "no effect" here means just that -- no effect: nothing is called,
> executed, etc. I do agree that that term is not formally defined, so
> there is a bit of wiggle room for implementations, but calling arbitrary
> routines because its convinient seems to be beyond any wiggle room.
> Especially as it is easy to do it correctly.
>
> That said, unless you can get a patch from a vendor (and that usually
> means that you're a favored customer), you probably ought to work around
> it - it does not seem hard to do so.

I'm sorry to vacillate, but I must add here that I completely /agree/ with 
Randy; I now disagree with my own previous post!

I agree that the implementation is /wrong/ to call Deallocate when the 
object is already null. (I was thinking about something a bit different 
when writing my previous post.) To do otherwise not only goes against what 
the RM says, but it also goes against good sense.

Apologies for any confusion!

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