Posix.String_List question

Posix.String_List question

[Stef Van Vlierberghe]

I recently reported a "bug" (Alsys 5.5.2 on HP9000/700), but the actual
code is so aggressive that I'm not sure who really is to blame. I see a
choice of the appliction, the vendor, POSIX1003.5 definition, or Ada.

The relevant code is :

  BYPASS_COPY_BACK : exception;

  procedure TRY_BREAK_IT (  LIST : in out POSIX_STRING_LIST ) is
  begin
    MAKE_EMPTY(LIST);
    raise BYPASS_COPY_BACK;
    -- if LIST is by copy the caller won't see we emptied it
  end;

  -- Make a LIST

  begin
    TRY_BREAK_IT ( LIST );
  exception
    when BYPASS_COPY_BACK => null;
  end;

  -- Make other list

  MAKE_EMPTY(LIST);
  -- This will free the dangling reference again (can be in use).

  -- Add to other list

After quite a while this code gets the heap corrupted.

Evidently the relevant piece of LRM is 6.2(7) : The execution of a
program is erroneous if its effect depends on which mechanism is selected
by the implementation.

But from there to blaming the appliction seems an awkward reasoning. Most
of all, application will often call cleanup code in exception handlers,
so if we blame the application then we should start looking for some *very*
skilled programmers.

The POSIX interface heavily suggests that we are dealing with an abstract
data type (i.e. we shouldn't care about implementation). But it isn't
explicit about the issue above.

The compiler vendor would probably know how to force a type to be
passed-by-reference... but perhaps one should not expect this to be done
if it isn't required ?

Hopefully a 9X compiler would use controlled types to implement the
Posix.String_List type, but even then, if the specification just sais
"[limited] private", an application might not be portable if it relied
on this implementation.

Perhaps a 9X update of 1003.5 might require call by reference semantics, or
even specifically non-limited controlled implementation (such that we can
copy without minding memory leaks).
--
Stef VAN VLIERBERGHE            Eurocontrol - Central Flow Management Unit
stef@cfmu.eurocontrol.be        Avenue des Arts 19H
Tel: +32 2 729 33 42            B-1040 BRUSSELS
Fax: +32 2 729 32 16            Belgium

Re: Posix.String_List question

[Ted Dennison]

In article <STEF.94Oct4234145@heron.cfmu.eurocontrol.be>, stef@heron.cfmu.eurocontrol.be (Stef Van Vlierberghe) writes:
|> 
|> I recently reported a "bug" (Alsys 5.5.2 on HP9000/700), but the actual
|> code is so aggressive that I'm not sure who really is to blame. I see a
|> choice of the appliction, the vendor, POSIX1003.5 definition, or Ada.
|> 
|> The relevant code is :
|> 
|>   BYPASS_COPY_BACK : exception;
|> 
|>   procedure TRY_BREAK_IT (  LIST : in out POSIX_STRING_LIST ) is
|>   begin
|>     MAKE_EMPTY(LIST);
|>     raise BYPASS_COPY_BACK;
|>     -- if LIST is by copy the caller won't see we emptied it
|>   end;
|> 
(rest of code deleted)
|> After quite a while this code gets the heap corrupted.
|> 
|> Evidently the relevant piece of LRM is 6.2(7) : The execution of a
|> program is erroneous if its effect depends on which mechanism is selected
|> by the implementation.
|> 

Also signifigant: LRM 6.2 (11-12):
"For parameters of array and record types, the parameter passing rules have
 these consequences:

  o  If the execution of a subprogram is abandoned as a result of an 
     exception, the final value of an acutal parameter of such a type can be
     either its value before the call or a value assigned to the formal 
     parameter during the execution of the subprogram."

Therefore this behavior is a bug in your code, NOT in the compiler.

To force a call by reference, simply pass TRY_BREAK_IT an object of type
"access POSIX_STRING_LIST". 

T.E.D.