From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2756 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: guard bug for strerror_r Date: Fri, 8 Feb 2013 15:38:25 -0500 Message-ID: <20130208203825.GM20323@brightrain.aerifal.cx> References: <1360342098.2983.360.camel@eris.loria.fr> <20130208165542.GW6181@port70.net> <1360344600.2983.365.camel@eris.loria.fr> <20130208100125.0d6bf697.idunham@lavabit.com> <20130208185918.GJ20323@brightrain.aerifal.cx> <1360353231.2983.382.camel@eris.loria.fr> <20130208200129.GK20323@brightrain.aerifal.cx> <1360355471.23424.79.camel@eris.loria.fr> 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 1360355916 14588 80.91.229.3 (8 Feb 2013 20:38:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Feb 2013 20:38:36 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2757-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 08 21:38:57 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 1U3uim-0004Q9-Ky for gllmg-musl@plane.gmane.org; Fri, 08 Feb 2013 21:38:56 +0100 Original-Received: (qmail 6116 invoked by uid 550); 8 Feb 2013 20:38:37 -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 6105 invoked from network); 8 Feb 2013 20:38:37 -0000 Content-Disposition: inline In-Reply-To: <1360355471.23424.79.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2756 Archived-At: On Fri, Feb 08, 2013 at 09:31:11PM +0100, Jens Gustedt wrote: > And, also I think that even before the _r version would have been a > good thing. I think the _r stands for reentrant, and for a function > that you would typically like to use in error or signal handlers, this > is a nice feature. Yes, but unfortunately the _r's and use of the word "reentrant" in issue 6 and earlier were all wrong; they used it to mean thread-safe, not reentrant. None of the _r functions are required to be reentrant. The term POSIX uses for reenatrant is "async-signal-safe", and strerror_r is not async-signal-safe. This is not just a theoretical limitation; in practice, most implementations probably fail to be reentrant due to use of a mutex protecting access to the current locale data. If/when musl adds any locale state that would need synchronization, I think our strerror should still be async-signal-safe, either using musl's recursive mutex (which is also a reentrant mutex) or lock-free atomic logic. Rich