From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/15 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Weekly reports: A Date: Tue, 24 May 2011 05:00:29 +0400 Message-ID: <20110524010029.GA11834@openwall.com> References: <4DDA9C8E.5020105@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1306198838 1142 80.91.229.12 (24 May 2011 01:00:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 24 May 2011 01:00:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-98-gllmg-musl=m.gmane.org@lists.openwall.com Tue May 24 03:00:34 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 1QOfz7-0007xM-AB for gllmg-musl@lo.gmane.org; Tue, 24 May 2011 03:00:33 +0200 Original-Received: (qmail 10141 invoked by uid 550); 24 May 2011 01:00:32 -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 10133 invoked from network); 24 May 2011 01:00:32 -0000 Content-Disposition: inline In-Reply-To: <4DDA9C8E.5020105@gmail.com> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:15 Archived-At: Luka, Rich - On Mon, May 23, 2011 at 07:42:38PM +0200, Luka Mar??eti?? wrote: > average, I expect to complete one task Rich described at > http://openwall.info/wiki/musl/unit-tests?s=libc per each report. I'll > start with nr. 1 (though there is nr. 0), as it allows me to correct and > complete the proof-of-skill test I've written earlier. (There are 13 test categories currently listed on the wiki page.) Sounds fine to me. I assume that you'll also proceed to wrap those tests into a framework once you have a few initial tests implemented. For "String operations testing" with "giant buffers (more than 2gb/4gb, only possible on 64-bit machines)" (part of task nr. 1 that you intend to work on now), you may consider having this test run on systems that don't have this much virtual memory (but are 64-bit capable). You may achieve this by mmap()'ing the same pages many times. When I needed a large continuous pseudo-allocation like that to explore/exploit some Linux kernel issues, I was able to allocate something like 190 GB (if I recall correctly) on an Alpha with 128 MB RAM (that was in 1999, before we got x86-64). (The kernel would spend 25 minutes parsing that data.) Of course, this enhancement should be optional (if implemented at all), and you need to have a version of code that actually allocates large buffers in straightforward manner (such that it's usable on systems that might have any issues with the repeated mmap() approach). In case you don't have a machine with over 4 GB RAM (even though these are common now) and need remote access to one, let me know. Oh, it's also useful to test buffer sizes close to 2 GB and slightly over 2 GB on 32-bit systems that are capable of such allocations. For "low and high byte content", I suggest that you include ability to test all byte values (for non-wide chars). glibc and many other libc's include implementations of string functions that use adds/bitmasks; these might contain bugs that only show up with specific byte values in specific character positions when the libc is built for specific CPUs. These are just some suggestions, which Rich might override. ;-) Thanks, Alexander