From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69142 invoked by alias); 18 Dec 2018 15:23:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 69130 invoked by uid 89); 18 Dec 2018 15:23:52 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*F:D*comcast.net X-HELO: resqmta-ch2-05v.sys.comcast.net Received: from resqmta-ch2-05v.sys.comcast.net (HELO resqmta-ch2-05v.sys.comcast.net) (69.252.207.37) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Dec 2018 15:23:50 +0000 Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id ZFNVgSuSPixl2ZHDogKXBz; Tue, 18 Dec 2018 15:23:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1545146628; bh=a9+NyxbZZAZ/jUHjZQUYQuNgTJmwbfmKGVpSVIbHdww=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=LLfpl/d3heIgedyjCdrVl2wbESEpqOI9WfAYw1PbKWLS9HnjVnEWUimXgF16iZ7JL 7xDS9hWzjpZdV1ED8Fiq9urfOCw5KTTru97rUD8xePXaP4Oegw2Y9ezrVwpO/XhtGA erF+DGV2RWSGy7M52zB9lZ2RwFhtRuh6QyCqZg7VoZnRwBjKl+es0TRMT6hhb7zSwy HG1iQ/8BWlY4jKSoPdqxzFPogGZsoF7VL4j24B4Nk4k59ZwnMEpbbdSrXT59g/374R igZLgRSe7UvV2/2Y3WVE3scVwVJCktUCaIzeKn4UN5yqyS2Qoe5SjdAs/H0bhlXUQN AuO44llS/ZSTg== Received: from pkoning.akdesign.com ([73.60.223.101]) by resomta-ch2-07v.sys.comcast.net with ESMTPSA id ZHDmghOwftoYiZHDngZIRz; Tue, 18 Dec 2018 15:23:48 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedtkedrudeikedgvdegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpefrrghulhcumfhonhhinhhguceophgruhhlkhhonhhinhhgsegtohhmtggrshhtrdhnvghtqeenucfkphepjeefrdeitddrvddvfedruddtudenucfrrghrrghmpehhvghlohepphhkohhnihhnghdrrghkuggvshhighhnrdgtohhmpdhinhgvthepjeefrdeitddrvddvfedruddtuddpmhgrihhlfhhrohhmpehprghulhhkohhnihhnghestghomhgtrghsthdrnhgvthdprhgtphhtthhopehsiigrsgholhgtshdrnhgrghihsegrrhhmrdgtohhmpdhrtghpthhtohepmhgrrhhtihhnrdhuvggtkhgvrhesmhgvugdruhhnihdqghhovghtthhinhhgvghnrdguvgdprhgtphhtthhopehmshgvsghorhesghhmrghilhdrtghomhdprhgtphhtthhopehlrgifsehrvgguhhgrthdrtghomhdprhgtphhtthhopehjohhsvghphhestghouggvshhouhhrtggvrhihrdgtohhmpdhrtghpthhtohepnhgusegrrhhmrdgtohhmpdhrtghpthhtohepghgttgdqphgrthgthhgvshesghgttgdrghhnuhdrohhrghdprhgtphhtthhopegvsghothgtrgiiohhusegruggrtghorhgvrdgtohhmpdhrtghpthhtohepfihilhgtohdrughijhh X-Xfinity-VMeta: sc=0;st=legit Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: [PATCH v4][C][ADA] use function descriptors instead of trampolines in C From: Paul Koning In-Reply-To: Date: Tue, 18 Dec 2018 15:23:00 -0000 Cc: "Uecker, Martin" , "msebor@gmail.com" , "law@redhat.com" , "joseph@codesourcery.com" , nd , "gcc-patches@gcc.gnu.org" , "ebotcazou@adacore.com" , Wilco Dijkstra Content-Transfer-Encoding: quoted-printable Message-Id: <5896AE4C-D296-4FAF-A809-7BACA532BBF5@comcast.net> References: <1534005653.22677.9.camel@med.uni-goettingen.de> <1534774021.5798.6.camel@med.uni-goettingen.de> <1534832264.15600.1.camel@med.uni-goettingen.de> <1534918133.4891.5.camel@med.uni-goettingen.de> <1541364511.30044.4.camel@med.uni-goettingen.de> <1544638361.17067.3.camel@med.uni-goettingen.de> <70f4a7b4-3741-52db-e362-699ef310a3b3@redhat.com> <1544781926.10326.8.camel@med.uni-goettingen.de> <17025085-3d47-0b16-c9d3-fec8d1ae9f39@redhat.com> <56b1e591-4d32-672f-6a30-11a9a0b167b7@gmail.com> <1544967934.14155.1.camel@med.uni-goettingen.de> <1545000327.30232.11.camel@med.uni-goettingen.de> <05b12e7e-b6dd-fa8d-94cb-35ec9c512950@arm.com> <1545070952.3328.5.camel@med.uni-goettingen.de> To: Szabolcs Nagy X-SW-Source: 2018-12/txt/msg01315.txt.bz2 > On Dec 17, 2018, at 2:23 PM, Szabolcs Nagy wrote: >=20 > On 17/12/2018 18:22, Uecker, Martin wrote: >>>=20 >>> ... >>=20 >> So a thread_local static variable for storing the static >> chain? >=20 > something like that, but the more i think about it the > harder it seems: the call site of the nested function > may not be under control of the nested function writer, > in particular the nested function may be called on a > different thread, and extern library apis are unlikely > to provide guarantees about this, so in general if a > nested function escapes into an extern library then > this cannot be relied on, which limits my original > idea again to cases where there is no escape (which i > think is not that useful). I'm not sure I understand "escape" of a nested function pointer.=20 Your description makes it sound like you're talking about a function being = called by someone who has been given the pointer, from outside the scope of= the function. That sounds like an illegal operation, exactly as it would = be if you attempted to reference an automatic variable via a pointer from o= utside the scope of that variable. Did I misunderstand? paul