[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E427511.8050804@gmail.com>
Date: Wed, 10 Aug 2011 14:09:53 +0200
From: Luka Marčetić <paxcoder@...il.com>
To: musl@...ts.openwall.com
Subject: Re: New daily reports - nothing
On 08/10/2011 06:59 AM, Rich Felker wrote:
> 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.
Of course.
> 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.)
This is from buf.c:
/**
** \file
** Tests functions for writing beyond string lenght and errno's they set
** tests: confstr, getcwd, getdelim, gethostname, iconv, mbstowcs,
snprintf,
** readlink, strfmon, strftime, wcstombs, ttyname_r, strerror_r
[...]
**/
If I wrote similar descriptions for all the tests, would that do? It
says what the test collection tests, and for which functions. I reckon
that, for example, the fact that `confstr` is tested using _CS_PATH
should stay in the source code. Esp. for things like numeric.c where
test data is huge.
> 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.
I'll make sure it builds with the newest musl as well. If you have some
more specific instructions, let me know. Or if there's something I miss,
please tell me. Thanks
> 4. Finish testing additional areas in the categories you're already
> working on.
I suppose you mean finish adding remaining tests to pthread_eintr.c. Or
is there something I missed in collections that I only call broken,
implying they would be done when fixed?
> 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.
So huge format string for snprintf, and weeding out glibc-specific tests
from autoconf tests? Where can I get the latter? Do I rewrite them, or
just try to incorporate into cluts (I'm guessing they're GPL, so...).
> 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.
Ok, I'll do that.
Thanks for the instructions, Rich.
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.
