From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/113 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: errno (was: Weekly reports - B) Date: Wed, 6 Jul 2011 22:56:29 -0400 Message-ID: <20110707025629.GE520@brightrain.aerifal.cx> References: <4DF12B1D.7050106@gmail.com> <20110613021130.GA21268@openwall.com> <20110613022221.GO191@brightrain.aerifal.cx> <20110613025655.GA21653@openwall.com> <20110613045418.GQ191@brightrain.aerifal.cx> <20110706113508.GA21773@openwall.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1310007798 5287 80.91.229.12 (7 Jul 2011 03:03:18 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 7 Jul 2011 03:03:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-197-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 07 05:03:11 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Qeerv-0002f6-6G for gllmg-musl@lo.gmane.org; Thu, 07 Jul 2011 05:03:11 +0200 Original-Received: (qmail 28327 invoked by uid 550); 7 Jul 2011 03:03:10 -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 28305 invoked from network); 7 Jul 2011 03:03:09 -0000 Content-Disposition: inline In-Reply-To: <20110706113508.GA21773@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:113 Archived-At: On Wed, Jul 06, 2011 at 03:35:08PM +0400, Solar Designer wrote: > Rich, > > On Mon, Jun 13, 2011 at 12:54:18AM -0400, Rich Felker wrote: > > ... errno is a macro and has been for a > > long time (ever since threads) on most systems. It's required by the > > standard to be an lvalue macro. > > Any idea why glibc has __set_errno() internally instead of assigning to > its errno directly, then? The implementation for __set_errno() does a > direct assignment anyway. What did the glibc developers need > __set_errno() for if errno is required to be an lvalue, and do they > still need __set_errno() or is it legacy? While this doesn't necessarily answer the historical question of whether or why it may have been needed, I think part of the reason for __set_errno (especiall in uclibc which uses a similar approach) might be keeping down code size or improving performance. Simple assignment to errno requires saving the value to be stored to errno in a non-call-clobbered register or on the stack, making a call to __errno_location, then reading back the saved error value and storing it at the address returned by __errno_location. On the other hand, with __set_errno, the process is just a single function call and the error value does not need to be saved for use after the call returns. Further, with NPTL's TLS model, it's possible to make __set_errno more efficient than using __errno_location would be. The latter is basically: mov %gs:0,%eax add $ERRNO_OFFSET,%eax ret while __set_errno can be purely: mov 4(%esp),%eax mov %eax,%gs:ERRNO_OFFSET ret And if you declare it regparm, you could even throw away the first instruction... Or you could just make it an inline function and get even bigger benefits (no actual call, on register spills, etc.) Personally, in musl I've avoided doing things like this in favor of simplicity. Presumably errno getting set should be a fairly uncommon occurrance anyway, so speed isn't all that important, and I like code that reads as plain C that could just as well be part of any implementation of the standard library rather than being full of implementation-specific tricks... Rich