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.