From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3551 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Use of size_t and ssize_t in mseek Date: Thu, 4 Jul 2013 11:26:54 -0400 Message-ID: <20130704152654.GP29800@brightrain.aerifal.cx> References: <20130629154859.GI29800@brightrain.aerifal.cx> <1372521678.8324.18.camel@eris.loria.fr> <20130629161338.GK29800@brightrain.aerifal.cx> <1372523967.8324.19.camel@eris.loria.fr> <20130704012800.GK29800@brightrain.aerifal.cx> <1372918318.16412.164.camel@eris.loria.fr> <20130704063740.GL29800@brightrain.aerifal.cx> <1372921889.16412.167.camel@eris.loria.fr> <20130704081245.GN29800@brightrain.aerifal.cx> <20130704111054.GY15323@port70.net> 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 1372951625 3699 80.91.229.3 (4 Jul 2013 15:27:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Jul 2013 15:27:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3555-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 04 17:27:07 2013 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 1UulR5-0005l1-D9 for gllmg-musl@plane.gmane.org; Thu, 04 Jul 2013 17:27:07 +0200 Original-Received: (qmail 15518 invoked by uid 550); 4 Jul 2013 15:27:06 -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 15510 invoked from network); 4 Jul 2013 15:27:06 -0000 Content-Disposition: inline In-Reply-To: <20130704111054.GY15323@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3551 Archived-At: On Thu, Jul 04, 2013 at 01:10:54PM +0200, Szabolcs Nagy wrote: > * Rich Felker [2013-07-04 04:12:45 -0400]: > > On Thu, Jul 04, 2013 at 09:11:29AM +0200, Jens Gustedt wrote: > > > > qsort_s can store the comparison function and context in TLS, and then > > > > pass to qsort a comparison function that grabs these from TLS and > > > > calls the original comparison function with the context pointer. This > > > > is valid assuming qsort does not run the comparisons in new threads. > > > > > > sure, but for an execution of qsort_s this would have a lot of > > > indirections and a call to TLS for every comparison. For performance > > > sensible functions like this, this doesn't sound very attractive. > > > > If it's inside musl, the TLS dereference is very cheap on most archs: > > it's just a constant offset from the thread pointer. Same if the code > > were static linked in the main program. Otherwise, if it's a dynamic > > library, then yes it would be fairly costly, like you say. > > it seems to me that if a qsort_s call sets the tls and then before > the callee reads that pointer a signal interrupts with a handler that > calls qsort_s again then the tls is overwritten by another pointer > > so you lose signal-safety with the tls design As long as qsort_s saves the old value from TLS on its stack and restores it before returning, you don't lose AS-safety except in the case of a longjmp out of qsort_s. But I agree this is a negative aspect of the possible design. Rich