[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 10 Aug 2011 00:59:33 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: New daily reports - nothing
On Wed, Aug 10, 2011 at 03:34:24AM +0200, Luka Marčetić wrote:
> Nothing to report for today, I'm afraid.
> Not much time left either. I hoped you'd suggest what to do, but I
> had to spend time fixing stuff anyway. And since I still do, my
> priorities are:
>
> - Fix and commit buf.c *
> - Fix other tests that are still broken (setuid, alloc)
> - Complete the started ones (pthread_eintr)
As I see it, what you've got (in varying stages of completeness) is
categories 1, 2, 3, 6, 8, and 9, from the project description here:
http://openwall.info/wiki/musl/unit-tests
Here are the things I would like you to focus on right now, roughly in
order of priority:
1. Fixing issues with test validity, like the buffer overflow/heap
corruption issues that make it impossible to actually detect failure.
This is a must.
2. Documenting the tests you have: what assertions they test. As
examples, "memcpy does not read past the end of the source buffer", or
"pthread_mutex_lock does not return EINTR when a signal is handled
while waiting for the lock". Along with that, a description of what
conditions the test covers (since for most of the tests, there's
theoretically a near-infinite set of possible inputs, and you can only
test a "representative" subset).
(I know you already have pretty good comments in the code, but what
I'm talking about is higher-level documentation, whether in comments
or separate from the source, about the larger purpose of the code and
what each test is checking.)
3. Cleaning up the build system and source to make sure it builds
without modification (except perhaps CFLAGS tweaks) on fairly recent
glibc and musl version.
4. Finish testing additional areas in the categories you're already
working on.
5. Test categories 4 and 5. I think it would be nice to pull in some
existing third-party (e.g. GNU) tests for these, but clean them up (as
in the project description) to avoid checking for GNU-specific stuff
and not to bail out as soon as the first test fails.
One thing I'd like you to drop for now is working on the setuid test.
It's been a time sink, and based on the work and discussion we already
did (which were very valuable in themselves), I have a working test
for it. You're welcome to incorporate that in cluts (preferably after
GSoC). I know this is kinda frustrating, but we really don't have time
for you to keep trying to fix it alongside all the other work that
remains to be done.
Rich
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.
