[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 27 May 2011 22:02:38 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
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.
Rich
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.
