GSoC

GSoC

[Лайто]

Hello.
I'm a student with some knowledges of basic Linux and C programming 
concepts, and I want to join some small open source project to get a 
more of experience. Can I join your project (libc unit tests), if I 
already apply via GSoC with Openwall?

Re: GSoC

[Solar Designer]

On Fri, Apr 08, 2011 at 05:12:06PM +0700, Лайто wrote:
> I'm a student with some knowledges of basic Linux and C programming 
> concepts, and I want to join some small open source project to get a 
> more of experience. Can I join your project (libc unit tests), if I 
> already apply via GSoC with Openwall?

Yes, you can.  In fact, the libc unit tests task is listed on Openwall's
ideas page.

Rich - this student expressed interest in some of our tasks, including
libc unit tests, so I suggested that he joins this mailing list.  You
could want to define a small task for him to work on - and we might gain
a contributor, whether under GSoC or not.

Thanks,

Alexander

Re: GSoC

[Solar Designer]

It looks like the student's Cyrillic name (or rather, a specific
Cyrillic charset) triggers Rich's spam filter.  Let me try again with
the name removed (replaced with dots). :-)

On Fri, Apr 08, 2011 at 02:37:44PM +0400, Solar Designer wrote:
> On Fri, Apr 08, 2011 at 05:12:06PM +0700, ..... wrote:
> > I'm a student with some knowledges of basic Linux and C programming 
> > concepts, and I want to join some small open source project to get a 
> > more of experience. Can I join your project (libc unit tests), if I 
> > already apply via GSoC with Openwall?
> 
> Yes, you can.  In fact, the libc unit tests task is listed on Openwall's
> ideas page.
> 
> Rich - this student expressed interest in some of our tasks, including
> libc unit tests, so I suggested that he joins this mailing list.  You
> could want to define a small task for him to work on - and we might gain
> a contributor, whether under GSoC or not.
> 
> Thanks,
> 
> Alexander

Re: GSoC

[Rich Felker]

On Fri, Apr 08, 2011 at 02:49:42PM +0400, Solar Designer wrote:
> It looks like the student's Cyrillic name (or rather, a specific
> Cyrillic charset) triggers Rich's spam filter.  Let me try again with
> the name removed (replaced with dots). :-)

Sorry. I've taken that filter off now. For what it's worth, adding
this to your .muttrc will prevent mutt from choosing legacy charsets
and always send UTF-8 (or ASCII if all the characters fit in ASCII):

set send_charset="us-ascii:utf-8"

Note that musl's iconv does not yet support KOI-8R, so I can't read
messages sent with that encoding. I am planning to overhaul the legacy
charset support in iconv.c soon though. Suppose I should add a list of
"important" charsets to the 1.0 wishlist...

Rich

Re: GSoC

[Rich Felker]

On Fri, Apr 08, 2011 at 05:12:06PM +0700, Лайто wrote:
> Hello.
> I'm a student with some knowledges of basic Linux and C programming
> concepts, and I want to join some small open source project to get a
> more of experience. Can I join your project (libc unit tests), if I
> already apply via GSoC with Openwall?

Here's one test that would be worthwhile and hopefully not too hard:

Write a program which loops many times allocating and freeing memory
in random sizes, keeping track of pointers to all the allocated blocks
and their sizes, up to a configurable very large maximum total
allocated amount, or allocation failure, whichever comes first. This
bookkeeping should be kept either in a global array or a single large
malloc-obtained object to avoid having it interact with the test. The
random numbers should use a user-chosen seed and fixed algorithm to
ensure that any abnormal results are reproducible.

Once this first phase finishes allocating memory, the program should
loop over the record of all allocated chunks and test that no chunk
overlaps with any other chunk by comparing their start and end
addresses (based on the saved pointers and sizes). Any overlap would
indicate either an under-allocation bug or memory corruption of some
sort.

I don't expect this to turn up any bugs, but it would be a nice
demonstration of confidence in musl's malloc implementation, which is
completely new and not based on existing sources.

Please don't get caught up in any fancy design for the test program.
It's not code that needs to be reusable or easily integrated with
other programs; it just needs to do its job.

By the way, I hope you'll avoid O(n^2) time in the overlap test.
There's an easy way to do that, and it'll also make it easy for your
program to generate a fragmentation diagram as an added feature. :-)

Rich