Strange side-effect of unchecked_deallocation

Strange side-effect of unchecked_deallocation

[Andreas.Schulz]

Boiled down to the essential, I have the following code :

type STRING_POINTER is access STRING;
DUMMY : STRING_POINTER := new STRING'("test");

procedure DEALLOCATE is new UNCHECKED_DEALLOCATION
  (STRING, STRING_POINTER);

function DEREF(X: in STRING_POINTER) return STRING is
begin
  return X.all;
end V;

procedure REPLACE ( BY_STRING : in STRING ) is
begin

  DUMMY := new STRING'(BY_STRING);
end;

So, REPLACE is intended to replace the current string of DUMMY by
a new string, like  REPLACE("new string");

However, things get strange when calling REPLACE(DEREF(DUMMY)).
In this case, DEALLOCATE(DUMMY) also messes up BY_STRING (resulting
in some strange empty array bounds range like (1880204..19) ).

Of course, the in the real code the fact that BY_STRING may in fact
be DUMMY.all is not visible where REPLACE is implemented, as well as
the fact that REPLACE changes DUMMY is invisible to the caller of
REPLACE, since the equivalent of DEREF only occasionally returns
DUMMY.all.

Now who is to blame, the compiler (VADSself Ada for Sun SPARC,
 Version 6.2.3(c)) or the designer(s) ?

Andreas

-------------------==== Posted via Deja News ====-----------------------
      http://www.dejanews.com/     Search, Read, Post to Usenet

Re: Strange side-effect of unchecked_deallocation

[Stephen Leake]

Andreas.Schulz@ri.dasa.de wrote:
> 
> Boiled down to the essential, I have the following code :
> 
> type STRING_POINTER is access STRING;
> DUMMY : STRING_POINTER := new STRING'("test");
> 
> procedure DEALLOCATE is new UNCHECKED_DEALLOCATION
>   (STRING, STRING_POINTER);
> 
> function DEREF(X: in STRING_POINTER) return STRING is
> begin
>   return X.all;
> end V;
> 
> procedure REPLACE ( BY_STRING : in STRING ) is
> begin

    DEALLOCATE (DUMMY); -- you forgot this?
 
>   DUMMY := new STRING'(BY_STRING);
> end;
> 
> However, things get strange when calling REPLACE(DEREF(DUMMY)).
> In this case, DEALLOCATE(DUMMY) also messes up BY_STRING (resulting
> in some strange empty array bounds range like (1880204..19) ).

That's why it's called Unchecked_Deallocation, instead of
Nice_Safe_Deallocation :)
 
> Now who is to blame, the compiler (VADSself Ada for Sun SPARC,
>  Version 6.2.3(c)) or the designer(s) ?

not the compiler :)

Actually, the behavior in this case is implementation defined, so
another compiler might do something different (for example, if it passes
By_String by copy instead of reference). But it isn't safe, and it isn't
portable.

You can add reference counting; DEREF should indicate that DUMMY is in
use, so REPLACE won't deallocate it. You need a limited controlled type
to do this right.

-- 
- Stephe