From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/61 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Weekly reports - B Date: Mon, 13 Jun 2011 00:54:18 -0400 Message-ID: <20110613045418.GQ191@brightrain.aerifal.cx> References: <4DF12B1D.7050106@gmail.com> <20110613021130.GA21268@openwall.com> <20110613022221.GO191@brightrain.aerifal.cx> <20110613025655.GA21653@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 1307941305 15103 80.91.229.12 (13 Jun 2011 05:01:45 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Jun 2011 05:01:45 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-145-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jun 13 07:01:39 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 1QVzHL-0006LK-Dd for gllmg-musl@lo.gmane.org; Mon, 13 Jun 2011 07:01:35 +0200 Original-Received: (qmail 22110 invoked by uid 550); 13 Jun 2011 05:01:34 -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 22102 invoked from network); 13 Jun 2011 05:01:34 -0000 Content-Disposition: inline In-Reply-To: <20110613025655.GA21653@openwall.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:61 Archived-At: On Mon, Jun 13, 2011 at 06:56:55AM +0400, Solar Designer wrote: > > but another way to achieve the same thing would be to install > > the signal handler with SA_NOMASK so the SIGSEGV never gets masked to > > [...] > > Thank you for mentioning these. > > For cluts, I think it'd be best not to go for them, though - they might > make cluts unnecessarily less portable. That's a good point. I seem to recall some systems (including older Linux) having broken SA_NOMASK. > > > Please avoid assignments to errno. Use your own variable instead. > > > > Is this just a stylistic preference, or do you have a reason it could > > be problematic? > > Mostly a stylistic preference. errno is defined to have a specific kind > of values assigned to it, by libc. Reusing a variable for something > different than its original purpose makes the source code more difficult > to understand (even if very slightly). > > As to actual potential issues: > > 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. > 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. Note that even strerror and perror can clobber errno if they encounter an internal error, so if you want to portably print an error message before acting on the error, you really need to save the value of errno right away. 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... Rich