Date: Wed, 13 Jul 2011 21:29:06 +0200 From: Luka Marčetić <paxcoder@...il.com> To: musl@...ts.openwall.com Subject: Re: cluts review 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.