[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E1DF202.4000106@gmail.com>
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.
