Re: Quick question regarding limited type return syntax

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 14-08-02 19:56 , Dmitry A. Kazakov wrote:
> On Sat, 02 Aug 2014 10:34:53 -0400, Robert A Duff wrote:
> 
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> On Sat, 02 Aug 2014 09:20:45 -0400, Robert A Duff wrote:
>>>
>>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>>>
>>>>> ...Dispatching calls
>>>>> through class-wide access discriminants upon initialization/finalization.
>>>>
>>>> Can you please give an example of what you mean?
>>>
>>> Components not discriminants. I had Rosen's trick in mind:
>>>
>>>    type T is ...
>>>        Self : not null access T := T'Unchecked_Access;
>>
>> Sorry, I still don't get it.  I don't see any class-wide types or
>> dispatching calls there.  Also, it's illegal as written (the Rosen trick
>> is only allowed for limited types.)  Perhaps a complete compilable
>> example would help illustrate the language anomaly you are talking
>> about.
> 
> with Ada.Finalization;
> with Ada.Text_IO;
> procedure Test is
>    package P is
>       type T is new Ada.Finalization.Limited_Controlled with record
>          Self : not null access T'Class := T'Unchecked_Access;
>       end record;
>       overriding procedure Initialize (X : in out T);
>       procedure Foo (X : in out T) is null;
>    end P;
>    
>    package body P is
>       procedure Initialize (X : in out T) is
>       begin
>          X.Self.Foo;
>       end Initialize;   
>    end P;
>    
>    package Q is
>       use P;
>       type S is new T with record
>          I : Integer;
>       end record;
>       overriding procedure Initialize (X : in out S);
>       overriding procedure Foo (X : in out S);
>    end Q;
>    
>    package body Q is
>       procedure Initialize (X : in out S) is
>       begin
>          T (X).Initialize;
>          X.I := 1;
>       end Initialize;
>       procedure Foo (X : in out S) is
>       begin
>          X.I := X.I + 1;
>       end Foo;
>    end Q;
>    
>    Y : Q.S;
> begin
>    Ada.Text_IO.Put_Line (Integer'Image (Y.I));
> end Test;

(Dmitry, I find it quite annoying that you just dump this code on us
without bothering to explain why you think it shows some problem in Ada.)

The code indeed accesses an uninitialized datum: when Y is initialized,
Initialize (S) calls Initialize (T), which makes a dispatching call to
Foo (S), which accesses the component S.I, which is not yet initialized.

The flow of control in the example is a bit sneaky, but the
self-referring component T.Self is in no way essential to the
sneakiness; the same could be achieved by simply making a redispatching
call to Foo in Initialize(T).

There are many other ways to create even sneakier flow of control with
even more obscure opportunities for accessing uninitialized data.

Perhaps you have some personal design and coding rules which would
prevent access to uninitialized data except for the kind of code shown
in the example? That is, perhaps the ability to write such code in Ada
breaks the safety of your design and coding rules? Perhaps the rule is
that the Initialize operation of a derived type should first call
Initialize on the parent type, and only then initialize the components
added in the derivation (the extension components)? That is not a bad
rule, but combining it with (re-)dispatching calls to operations
overridden in the derived type obviously invites errors of the kind
shown in the example.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .