Re: Preventing type extensions

["Vinzent Hoefler" <nntp-2010-09@t-domaingrabbing.de>]

On Wed, 22 Sep 2010 22:38:22 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> wrote:

> On Wed, 22 Sep 2010 22:25:46 +0200, Florian Weimer wrote:
>
>>> Stack/heap allocation refer to a memory management policy rather than
>>> physical location. This boundary is very sharp: the stack policy  
>>> presumes
>>> two important constraints: 1. LIFO ordering, 2. Ownership by the task.
>>
>> Neither is true if you can create tasks dynamically.  Instead of using
>> an allocator, you just wrap the object to be created in a task, where
>> you put it on the stack.  In effect, you have bypassed both
>> constraints (because the owner is not you, but some other task).
>
> No, unfortunately task entries returning objects are not allowed, if that
> is what you meant.

Florian probably meant it more like this:

|  task type Data_Task is
|      entry Get_Data (Y : out Data_Access);
|  end Data_Task;
|
|  task body Data_Task is
|     X : aliased Data;
|  begin
|     loop
|        accept Leak_Data (Y : out Data_Access) do
|           Y := X'Unchecked_Access;
|        end Leak_Data;
|     end loop;
|  end Data_Task;

A proper set of Restrictions pragmas should easily prevent this.

In fact, "pragma Restrictions (No_Unchecked_Access)" should even be
sufficient to prevent a task from leaking it's own data to the outside.

And if the task allocated X on the heap, the access types wouldn't match
anyway.


Vinzent.

-- 
There is no signature.