From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5727 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: PATCH: don't call cleanup handlers after a regular return from the thread start function Date: Tue, 5 Aug 2014 16:29:45 -0400 Message-ID: <20140805202945.GJ1674@brightrain.aerifal.cx> References: <1407257494.24324.241.camel@eris.loria.fr> <20140805170942.GG1674@brightrain.aerifal.cx> <1407265576.24324.248.camel@eris.loria.fr> <20140805194117.GI1674@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1407270606 21306 80.91.229.3 (5 Aug 2014 20:30:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Aug 2014 20:30:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5732-gllmg-musl=m.gmane.org@lists.openwall.com Tue Aug 05 22:29:59 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XElMs-0005ue-5a for gllmg-musl@plane.gmane.org; Tue, 05 Aug 2014 22:29:58 +0200 Original-Received: (qmail 7546 invoked by uid 550); 5 Aug 2014 20:29:57 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7538 invoked from network); 5 Aug 2014 20:29:57 -0000 Content-Disposition: inline In-Reply-To: <20140805194117.GI1674@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5727 Archived-At: On Tue, Aug 05, 2014 at 03:41:17PM -0400, Rich Felker wrote: > > But I have another reason for wanting that, future compatibility with > > C threads. Programs that are written for C threads will not be aware > > of such interdictions. Concretely in our case of my C thread v3 patch > > a user can longjmp from a once-init-handler (written by her or him) > > through pthread_once (in libc, for musl with pthread_cleanup_push) to > > the thread start function (again user code) and then return from > > there. (All of this seems to be allowed by POSIX) > > Such a longjmp is UB unless it's explicitly permitted by the standard > -- same as longjmp out of qsort. There's no guarantee to a function > called as a callback from the standard library that the calling > function does not have internal state which would be left in an > inconsistent state by longjmp'ing out. Actually, I can't find the text which supports this, which is odd since it seems to be common knowledge that you can implement qsort with algorithms that use allocation if it succeeds. The standard _does_ contain such text for atexit and at_quick_exit, and I suppose qsort is covered by the strict interface contract for the comparison function (the "shall return" requirement cannot be met if the function calls longjmp). The only other standard library function I'm aware of which calls back to application code is call_once, so it's not clear to me whether lack of consideration of longjmp for call_once is an omission (likely) or an allowance for it to use longjmp (in which the "exactly once" is probably under-specified, especially since call_once does not synchronize until "completion of an effective call"). Rich