Date: Wed, 13 Jul 2011 21:52:01 +0400 From: Solar Designer <solar@...nwall.com> To: musl@...ts.openwall.com Subject: Re: cluts review Luka, Rich - On Wed, Jul 13, 2011 at 07:25:07PM +0200, Luka Mar??eti?? wrote: > Anyway, so I need SA_NODEFER because the handler doesn't return, > understood. As for the sigsetjmp and stuff, that's what we had before. > And yet again, I forgot why it was deprecated (I think there was signal > structs being different across platforms, though I'm not sure where the > problem was), but anyway Rich suggested sigaction. I think you're confusing things. Maybe Rich suggested that you use sigaction() instead of signal()? That's fine, but it has nothing to do with the choice of setjmp() vs. sigsetjmp(). > This reminds me, the code is distinctly C99, and it tests SUSv4 > functions, so if you don't mind, for cluts, I'll use those two standards I am fine with limiting cluts to newer systems if Rich is fine with that. What I am saying here about sig* has little to do with newer vs. older systems. It's just that sigsetjmp() and friends appears to be a cleaner way to deal with the problem. Quite in line with what you're advocating. > and go back to SA_NODEFER. OK, but there's a cleaner way to do it. > 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? > That's what I've said I've checked with buf.c. What exactly did you check/change? > P.S. Perhaps I should start thinking about how the final cluts.c will > look like, otherwise it might become hard to change all the test > collections later... Speaking of overall structure of cluts, I think it's not cluts.c but the building/linking of the individual test collections that you should decide on first. Right now, you have one top-level makefile only (BTW, the name "Makefile" is more standard on Unix-like systems), 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. 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. Thanks, Alexander
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.