From: "Luka Marčetić" <paxcoder@gmail.com>
To: musl@lists.openwall.com
Subject: Re: New daily reports - nothing
Date: Mon, 15 Aug 2011 16:14:12 +0200 [thread overview]
Message-ID: <4E4929B4.1090401@gmail.com> (raw)
In-Reply-To: <20110814200044.GM132@brightrain.aerifal.cx>
On 08/14/2011 10:00 PM, Rich Felker wrote:
> On Wed, Aug 10, 2011 at 12:59:33AM -0400, Rich Felker wrote:
>> 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
>> [...]
>> 2. Documenting the tests you have: what assertions they test. As
>> [...]
>> 3. Cleaning up the build system and source to make sure it builds
>> [...]
>> 4. Finish testing additional areas in the categories you're already
>> [...]
>> 5. Test categories 4 and 5. I think it would be nice to pull in some
> Luka, could you please reply with an estimate on how many hours of
> work you think each of these areas will take you and an intended
> schedule for how and when you plan to accomplish them?
>
> Rich
Hello.
Work required for the above:
1. Depends on what the issues really are. Eg. valgrind is clean on
alloc.c, but it still fails for musl on 64-bit, because I get nothing
allocated following vm_limit. Explicitly putting malloc() after it
works, but doing it via the function fails. It's really hard to debug
child processes (which is how a lot of collections are written), I
should perhaps try Alexander's method. But I really can't say how much
it'll take me - depends on inspiration and help i get from others. It's
been time consuming up until now, but I think I've polished it enough so
I just need to spot this one thing I'm missing and then correction won't
be a problem.
2. I've updated pthread_eintr.c. If there's something you want me to
expound on, let me know. I can try and generate doxygen docs now. Not
sure if we need more user documentation, but I could add a few more
sentences to README just so that people know what to expect when they
run ./cluts etc. (a few hours to setup, and update docs if there are errors)
3. I can make buf.c collection test whether MUSL is defined just as I've
recently have done for pthread_eintr.c. I'd appreciate if someone could
tell me how to add `install-musl` which should add an additional
-DMUSL=1 flag. (this and testing it shouldn't take more than a couple
hours).
4. and 5. Check IRC please about pthread_eintr.c. Also, I'd like to
finish string.c before starting new collections if that's fine with me.
Based on past experience, I believe that rewriting string.c will take me
about three days of intensive work. I can't give you my estimate for
tests 4 and 5 (sprintf and stdio tests), because other than the
"example" given in 4, I don't know what else will need to be tested, and
I don't know how exactly autoconf looks like.
Schedule for the above:
I can do 2 and 3 today, then start working on (either part of nr 5 or)
string.c, and after that, come back to 1. Now I can't commit after
Saturday, but I can still do nr 4, and after that 5 when I have time
(college starts, so maybe not right away).
When I'm done with 2 and 3 today, I can take a look at autoconf, and
perhaps give you an estimate for that.
If you have other suggestions, please let me know soon.
Luka
prev parent reply other threads:[~2011-08-15 14:14 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-03 22:14 New daily reports Luka Marčetić
2011-08-03 22:46 ` Solar Designer
2011-08-04 10:51 ` Luka Marčetić
2011-08-04 11:54 ` Solar Designer
2011-08-04 12:01 ` Luka Marčetić
2011-08-04 12:12 ` Solar Designer
2011-08-05 0:02 ` New daily reports - started pthread_eintr.c Luka Marčetić
2011-08-05 0:10 ` Solar Designer
2011-08-06 4:40 ` New daily reports - debugging alloc.c et al Luka Marčetić
2011-08-06 11:15 ` Szabolcs Nagy
2011-08-06 11:50 ` Szabolcs Nagy
2011-08-06 14:34 ` Szabolcs Nagy
2011-08-06 15:38 ` Szabolcs Nagy
2011-08-07 2:41 ` New daily reports - debugging alloc.c still Luka Marčetić
2011-08-07 2:50 ` Solar Designer
2011-08-07 7:32 ` Rich Felker
2011-08-07 22:25 ` Luka Marčetić
2011-08-09 3:02 ` New daily reports - buf.c Luka Marčetić
2011-08-10 1:34 ` New daily reports - nothing Luka Marčetić
2011-08-10 1:38 ` Rich Felker
2011-08-10 11:47 ` Luka Marčetić
2011-08-10 2:02 ` Solar Designer
2011-08-10 11:23 ` Luka Marčetić
2011-08-10 11:56 ` Solar Designer
2011-08-10 12:13 ` Luka Marčetić
2011-08-10 2:07 ` Solar Designer
2011-08-10 2:12 ` Rich Felker
2011-08-10 4:59 ` Rich Felker
2011-08-10 12:09 ` Luka Marčetić
2011-08-10 12:44 ` Luka Marčetić
2011-08-10 14:25 ` Rich Felker
2011-08-10 17:21 ` Luka Marčetić
2011-08-10 17:33 ` Rich Felker
2011-08-10 18:23 ` Luka Marčetić
2011-08-10 18:21 ` Rich Felker
2011-08-10 18:34 ` Luka Marčetić
2011-08-10 18:33 ` Rich Felker
2011-08-14 20:00 ` Rich Felker
2011-08-15 14:14 ` Luka Marčetić [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E4929B4.1090401@gmail.com \
--to=paxcoder@gmail.com \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).