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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no 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!news3.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!193.201.147.71.MISMATCH!xlned.com!feeder3.xlned.com!feeder.erje.net!news2.arglkargh.de!news.n-ix.net!news.belwue.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Preventing type extensions
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <87iq2bfenl.fsf@mid.deneb.enyo.de>
 <66a3704c-54f9-4f04-8860-aa12f516134b@t3g2000vbb.googlegroups.com>
 <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>
Date: Wed, 22 Sep 2010 22:38:22 +0200
Message-ID: <v5fjxe9zr3v7$.wbmodvfn6eea.dlg@40tude.net>
NNTP-Posting-Date: 22 Sep 2010 22:38:20 CEST
NNTP-Posting-Host: a5b1e1db.newsspool4.arcor-online.net
X-Trace: 
 DXC=7MaGdH5lL[1d8Nb@@ZG@b=4IUK<Cl32<14Fo<]lROoR18kF<OcfhCO;K<IcI7U1L88[6LHn;2LCV>[<mhadbfdU;:bBjBNo6G;56Z6E=KUWa05
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:14199
Date: 2010-09-22T22:38:20+02:00
List-Id: <comp.lang.ada>

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. But if they were allowed, they would copy out. (I don't
consider the ugly limited return from functions. That was a language design
bug.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de