Re: cluts review

[Solar Designer <solar@openwall.com>]

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