From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/151 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?THVrYSBNYXLEjWV0acSH?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: cluts review Date: Wed, 13 Jul 2011 21:29:06 +0200 Message-ID: <4E1DF202.4000106@gmail.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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1310585453 5623 80.91.229.12 (13 Jul 2011 19:30:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 13 Jul 2011 19:30:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-235-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 13 21:30:46 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 1Qh58w-0003mC-Gy for gllmg-musl@lo.gmane.org; Wed, 13 Jul 2011 21:30:46 +0200 Original-Received: (qmail 1742 invoked by uid 550); 13 Jul 2011 19:30:45 -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 1734 invoked from network); 13 Jul 2011 19:30:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YO6tLafyho6oxELYLTT68urPykmhQBCzN3xM1a+W22A=; b=wY0rV2XV0p0Ds+Wb+anpX9TGkfSYzPho6giPuAY4zTuJrnrGSckuITLP3FrFRs4+Sq iNpZB5aU9Zwot3iSerg0JvRt3w71FOH4sDhxgbARppo7X6mzOeenBtHRoHoKlIKfMsw/ pVoJAmwymL88ufFWW9wRnF2Yrv0jNrfWa8HHo= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 In-Reply-To: <20110713175201.GA25532@openwall.com> Xref: news.gmane.org gmane.linux.lib.musl.general:151 Archived-At: 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, my comment is: Yes, but note that for sigsetjmp to do the same job, I'd need yet another global variable. So, given that SA_NODEFER is SUSv4 which I'm using anyway, I still regard it as cleaner than sigsetjmp. >> 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 :-( >> 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: 'function' is changed inside a switch loop only if no test is run (function>n, where n is the number of tests). If no tests are run, there should be no SIGABRT/SIGSEGV signals. If there is, it should crash the test collection so I can fix it. 'failed' indeed gets clobbered (we get a non-incremented value) if the above signals have been caught, but then is incremented after longjmp (actually, I think that's the one I did fix) 'err_expected' may be clobbered. it doesn't matter, as printing the error message that includes it won't happen. 'stream' - to be honest, I don't know why it reports that stream could be clobbered. I did check it, and it's set outside the sigset blocks, and shouldn't be changed > Right now, you have one top-level makefile only (BTW, > the name "Makefile" is more standard on Unix-like systems), Didn't know that, will rename, thanks. > which builds > all *.c files into their corresponding binary executables. And you > include your common code right into each C source. A cleaner way > would be to build the individual C files into *.o files and to get them > linked together as appropriate - so your common code is only compiled > once, and only some of its symbols are exported. I could make a rule for common files (that much I can manage), but make would then have to know what to link together. Being a make noob, I'm not sure what's the proper/expected form for .h files either. It's even a question whether it'd be of any use to me, given that my code doesn't compile into a single binary, it is multiple independent binaries, all including only some .h's. But if you know there's a better way, I'm open to it, and will cooperate. > Also, you could have a > separate Makefile under tests/, which you'd invoke with a sub-make, or > you could get rid of those tests/ and common/ subdirectories in order to > simplify the build process (cluts.c would then need to learn of the > tests to run by other means - e.g., by a filename prefix). Just some > thoughts. Hmm. > Thanks, > > Alexander Sorry for the late reply, I was afk. And I apologize if I'm touchy about my code (don't let that stop you from commenting, please). Thanks, -Luka