This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Google Summer of Code projects for the GNU C Library.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 21 Feb 2014 10:53:12 -0500
- Subject: Re: Google Summer of Code projects for the GNU C Library.
- Authentication-results: sourceware.org; auth=none
- References: <530548F5 dot 7090401 at redhat dot com> <CAGQ9bdwt6orzq0ap4UH7f7ZfAEMOGuxrSq0PBVcqW3hm3nrC-w at mail dot gmail dot com> <Pine dot LNX dot 4 dot 64 dot 1402210136090 dot 7834 at digraph dot polyomino dot org dot uk> <20140221125318 dot GA6229 at domone dot podge>
On 02/21/2014 07:53 AM, OndÅej BÃlka wrote:
> On Fri, Feb 21, 2014 at 01:45:31AM +0000, Joseph S. Myers wrote:
>> On Thu, 20 Feb 2014, Konstantin Serebryany wrote:
>>
>>> Idea for glibc GSoC project: instrument the glibc source with
>>> AddressSanitizer (asan).
>>> https://code.google.com/p/address-sanitizer/
>>> goal #1: test glibc itself for bugs like stack or global buffer overflow.
>>
>> I suspect most interesting such bugs are for cases involving extreme (but
>> valid) input that's currently not covered by the testsuite. In my
>> experience it's quite easy to find problems with memory allocation just by
>> looking for them; it might be interesting to have a project to review
>> allocations in glibc more thoroughly, especially where the size depends on
>> user input.
>>
> I already done review, most of these could be solved by not duplicating
> same allocation pattern in 100 of places. Using malloca and saturated
> arithmetic will dramaticaly cut number of possible errors.
Write up a project description for that?
https://sourceware.org/glibc/wiki/GSoC
Cheers,
Carlos.