Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 27 May 2011 22:02:38 -0400
From: Rich Felker <>
Subject: Re: Weekly reports: A

On Sat, May 28, 2011 at 02:37:46AM +0200, Luka Marčetić wrote:
> On 05/24/2011 03:13 AM, Rich Felker wrote:
> >>>  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.
> >I agree. I don't believe any such issues affect the current C
> >implementations in musl, but it would be nice to have the tests in
> >place in case anyone wants to add arch-specific asm versions.
> Hey guys.
> I would just like to point out that the above, combined with the
> "all alignments" requirement from the wiki means I'm essentially
> brute-forcing string.h functions. While I generally dislike the
> idea, it's a.. thorough approach.. I guess. As a slight remedy I'll

The whole point is to brute force all combinations of input that are
expected to make a difference to what paths the code might take.

> "brute force" with smaller buffers, and only do basic tests with
> huge ones. I hope that won't miss the point then. Will report how

Indeed of course you can't brute force all possible sequences of bytes
up to several GB. :-) I'll leave coming up with a reasonable
evalulation of what's needed and what's not as part of your task.


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.