From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/384 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?THVrYSBNYXLEjWV0acSH?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: New daily reports - nothing Date: Wed, 10 Aug 2011 14:09:53 +0200 Message-ID: <4E427511.8050804@gmail.com> References: <4E39C84F.8060705@gmail.com> <20110803224651.GB11437@openwall.com> <4E3A79B2.8090204@gmail.com> <4E3B331E.7050502@gmail.com> <4E3CC5AC.3070404@gmail.com> <4E3DFB5D.8040008@gmail.com> <20110807073224.GG132@brightrain.aerifal.cx> <4E3F10C7.4060601@gmail.com> <4E40A33F.7090804@gmail.com> <4E41E020.7020109@gmail.com> <20110810045933.GW132@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1312978344 2979 80.91.229.12 (10 Aug 2011 12:12:24 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 10 Aug 2011 12:12:24 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-385-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 10 14:12:17 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Qr7dw-0002GX-PS for gllmg-musl@lo.gmane.org; Wed, 10 Aug 2011 14:12:16 +0200 Original-Received: (qmail 3232 invoked by uid 550); 10 Aug 2011 12:12:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3223 invoked from network); 10 Aug 2011 12:12:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=TTDsmiir/+sMi29ilQiGdT5Zv5RMQ/OgUqForYxUWLQ=; b=t3PP9PtCBY9XpB2xBjPxIIP3Cmm+leG3PZzbGM1U31nmMHQSiO3/4PS9mCwSzEL6ud gVwlDlA6hYe13THMtJQN8pGakzwG0JO+wNLLMdmlXrhixv7hKcRq9cKkgH9aKkz5oLCS GnuOoGuhSRT+uzUe3EkiPwB1CbOQU5MhFHn0o= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110626 Icedove/3.1.11 In-Reply-To: <20110810045933.GW132@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:384 Archived-At: 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