mailing list of musl libc
 help / color / mirror / code / Atom feed
From: "Luka Marčetić" <paxcoder@gmail.com>
To: musl@lists.openwall.com
Subject: Re: New daily reports - nothing
Date: Wed, 10 Aug 2011 14:09:53 +0200	[thread overview]
Message-ID: <4E427511.8050804@gmail.com> (raw)
In-Reply-To: <20110810045933.GW132@brightrain.aerifal.cx>

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


  reply	other threads:[~2011-08-10 12:09 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ć [this message]
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ć

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=4E427511.8050804@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).