From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/62 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Weekly reports - B Date: Mon, 13 Jun 2011 10:48:45 +0400 Message-ID: <20110613064845.GA22390@openwall.com> References: <4DF12B1D.7050106@gmail.com> <20110613021130.GA21268@openwall.com> <20110613022221.GO191@brightrain.aerifal.cx> <20110613025655.GA21653@openwall.com> <20110613045418.GQ191@brightrain.aerifal.cx> 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 1307947823 9222 80.91.229.12 (13 Jun 2011 06:50:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Jun 2011 06:50:23 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-146-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 13 08:50:19 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 1QW0yZ-0003v7-AI for gllmg-musl@lo.gmane.org; Mon, 13 Jun 2011 08:50:19 +0200 Original-Received: (qmail 28103 invoked by uid 550); 13 Jun 2011 06:50:18 -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 28094 invoked from network); 13 Jun 2011 06:50:18 -0000 Content-Disposition: inline In-Reply-To: <20110613045418.GQ191@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:62 Archived-At: On Mon, Jun 13, 2011 at 12:54:18AM -0400, Rich Felker wrote: > On Mon, Jun 13, 2011 at 06:56:55AM +0400, Solar Designer wrote: > > IIRC, some ancient versions of glibc didn't allow programs to assign to > > errno at all, because it was declared as a macro (not a variable). That > > This sounds like an urban legend. 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. Oh, of course I did not recall correctly. Here's what I think this was about: old programs such as qmail (not maintained upstream since 1998) used "extern int errno;" instead of including errno.h, and indeed this failed when errno became a macro (for threads, as you correctly remind me). So this was an entirely different issue. > > Is it guaranteed that errno is preserved across libc calls that complete > > without error? Maybe not. I don't really know, and I'd prefer not to > > depend on that. > > Unless it's documented that a particular function can't, libc > functions can clobber errno all they like, whether or not they return > failure. The only thing they can't do is set it to 0, unless they put > some other nonzero (hopefully meaningful) value in it before > returning. I went to: http://pubs.opengroup.org/onlinepubs/009695399/functions/errno.html and it does say "No function in this volume of IEEE Std 1003.1-2001 shall set errno to 0. The setting of errno after a successful call to a function is unspecified unless the description of that function specifies that errno shall not be modified." Which not surprisingly matches what you wrote above. I was a bit puzzled why they decided to outlaw setting of errno to 0 by library functions, although this does make some sense to me (easy to achieve and preserves at least some recent error code for poorly written old programs). > This all makes using errno a little bit messy, but if libc functions > were required not to change errno except when reporting an error, > pretty much every libc function that uses other libc functions would > be full of useless bloat and slowdowns saving and restoring errno > values... Good point. I guess they'd resort to calling other than exported versions of the functions, though. But this could mean extra function call overhead for the exported versions... Alexander