From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/156 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: cluts review Date: Thu, 14 Jul 2011 00:39:45 +0400 Message-ID: <20110713203945.GA26271@openwall.com> References: <20110713110723.GA22153@openwall.com> <4E1D8964.3020502@gmail.com> <20110713160327.GA24660@openwall.com> <4E1DCDE5.1040008@gmail.com> <20110713170551.GA25095@openwall.com> <4E1DD4F3.5090206@gmail.com> <20110713175201.GA25532@openwall.com> <4E1DF202.4000106@gmail.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 1310589594 30794 80.91.229.12 (13 Jul 2011 20:39:54 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2011 20:39:54 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-240-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 13 22:39:51 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 1Qh6Dm-0000by-Vk for gllmg-musl@lo.gmane.org; Wed, 13 Jul 2011 22:39:51 +0200 Original-Received: (qmail 3458 invoked by uid 550); 13 Jul 2011 20:39:50 -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 3450 invoked from network); 13 Jul 2011 20:39:50 -0000 Content-Disposition: inline In-Reply-To: <4E1DF202.4000106@gmail.com> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:156 Archived-At: On Wed, Jul 13, 2011 at 09:29:06PM +0200, Luka Mar??eti?? wrote: > On 07/13/2011 07:52 PM, Solar Designer wrote: > >>and go back to SA_NODEFER. > >OK, but there's a cleaner way to do it. > > If you mean SA_NODEFER is new, No, I don't. > my comment is: Yes, but note that for > sigsetjmp to do the same job, I'd need yet another global variable. No, you wouldn't. You already have a jmp_buf variable, which you'd replace with a sigjmp_buf one. It's a trivial change, really. (I wrote the above before I saw Rich's response about the same.) > >>Oh, and I do believe I know aht "clobbered" means (overwriting the new > >>value of the variable with the old one, from when the context was saved, > >>right?). > >Yes. Do you know in what cases this happens, and how to prevent it? > > If you don't mind i'll skip this one :-( Rich might be able to provide a better / more correct answer (I'd be interested), but here's my understanding: The clobbering happens when those variables are kept in registers rather than in memory (on stack). To prevent it from happening, you may force the compiler not to place the variables in registers. One way to do it is to take the variable's address: (void) &var; (I am not sure what guarantees this provides. IIRC, it was documented to provide the needed safety under GNU C.) Another is to declare it "volatile", but this does a bit more than is needed (so has extra performance impact). Better yet, structure your function such that there are no variables to clobber. If you put your sigsetjmp() at the very beginning of the function, before any local variable is assigned a value, there's nothing to clobber yet. > >>That's what I've said I've checked with buf.c. > >What exactly did you check/change? > > I don't remember if I had to change anything, but I can comment on > -Wclobbered messages, that might convince you: ... So basically you review the code and then knowingly ignore the warnings? That's not great. Alexander