Re: cluts review

["Luka Marčetić" <paxcoder@gmail.com>]

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