From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,29d8139471e3f53e
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news1.google.com!news.glorb.com!news2.glorb.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: "Vinzent Hoefler" <nntp-2010-09@t-domaingrabbing.de>
Newsgroups: comp.lang.ada
Subject: Re: Preventing type extensions
Date: Wed, 22 Sep 2010 23:25:39 +0200
Message-ID: <op.vjgds1bud20q5n@jellix.jlfencey.com>
References: <87iq2bfenl.fsf@mid.deneb.enyo.de>
 <87d3sib44t.fsf@mid.deneb.enyo.de>
 <134q4k2ly2pf4$.17nlv1q6q5ivo.dlg@40tude.net>
 <4c8dec8e$0$6990$9b4e6d93@newsspool4.arcor-online.net>
 <epkb3s8dfxk0$.1qdvo5vg2fsgh.dlg@40tude.net>
 <8f6cceFrv2U1@mid.individual.net>
 <135a7dc9-3943-45e4-884b-3cc6bce3db0a@q18g2000vbm.googlegroups.com>
 <i6m45c$gjp$2@news.eternal-september.org>
 <c75a88c5-1d51-4342-904a-743e41adeb7f@k9g2000vbo.googlegroups.com>
 <i7afm3$dn8$1@news.eternal-september.org>
 <a9a93110-c5a1-41cb-b36a-0e8da7f4cacf@q26g2000vbn.googlegroups.com>
 <i7air8$q3k$1@news.eternal-september.org>
 <81799aab-a2e8-4390-8f42-abceaa5fc032@m1g2000vbh.googlegroups.com>
 <i7cd4n$9tj$1@news.eternal-september.org>
 <5c0d7798-ba09-4bd0-a28f-f1b028cce927@y3g2000vbm.googlegroups.com>
 <87r5gl8tky.fsf@ludovic-brenta.org> <8762xxd0az.fsf@mid.deneb.enyo.de>
 <1oqw5btmqxu43$.1tzbqy0zcwep8.dlg@40tude.net>
 <87zkv9a5kl.fsf@mid.deneb.enyo.de>
 <v5fjxe9zr3v7$.wbmodvfn6eea.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
X-Trace: individual.net LlAFa2gfUitBO7VMP2lQbQqQopaWw4pWESiUvLs7z2rDsv1q9e
Cancel-Lock: sha1:VQra9A1N16bzVpdGCvReUObpRg0=
User-Agent: Opera Mail/10.62 (Win32)
Xref: g2news1.google.com comp.lang.ada:14202
Date: 2010-09-22T23:25:39+02:00
List-Id: <comp.lang.ada>

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.