[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
