All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@kernel.org>
To: Derek M Jones <derek@knosof.co.uk>
Cc: linux-sparse@vger.kernel.org
Subject: Re: Sparse and the Google Summer of Code 2008
Date: Tue, 11 Mar 2008 21:28:53 -0700	[thread overview]
Message-ID: <47D75C05.4090807@kernel.org> (raw)
In-Reply-To: <47D734C2.1020903@knosof.co.uk>

[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]

Derek M Jones wrote:
>>> I know, last year was not all that successful, but maybe
>>> there will be more applications this year. I've got some
>>> ideas about abstract interpretation for one. I can't promise
>>> that I'll choose sparse, there should be lots of interesting
>>> projects this year, but there are other people as well.
>> At least one other person has asked about Sparse and SoC, which
>> suggests that some interest exists.  I'll work on getting the
>> org forms filled out today.
>>
>> If anyone else on the Sparse list has an interest in mentoring, please
>> let me know as soon as possible.
> 
> The ideas so far proposed are major undertakings.  The sort of
> thing a summer student will only scratch the surface of.

To clarify, I wouldn't expect a student project to do everything
necessary to complete any of the areas I mentioned.  I wouldn't expect
complete handling of contexts, or a complete port of an extensive test
suite.  (And the comment about code generation falls under "sarcastic
offhand remark", not "project suggestion"; anyone wanting to do that
should scale back their expectations significantly unless they have
lots of compiler experience.)  On the other hand, a student project
could reasonably add one or two additional things to context checking,
or do a proof-of-concept port of a handful of tests with some
underlying infrastructure.

> I think it would be useful to analyze the Linux bug history,
> looking for known faults and their fixes, that are currently not
> detected by Sparse, but which look like they are amenable to static
> detection.
> If more faults are required there is always the BSD bug list.
> 
> If the existing faults were categorized it would give some idea
> of the kinds of constructs that ought to be searched for.

Agreed entirely, and that sounds like an excellent project possibility.
Any additional useful warning in Sparse represents a good contribution.

- Josh Triplett


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

  parent reply	other threads:[~2008-03-12  4:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-11 17:38 Sparse and the Google Summer of Code 2008 Alexey Zaytsev
2008-03-11 18:20 ` Josh Triplett
2008-03-11 19:08   ` James Westby
2008-03-11 22:10   ` Christopher Li
2008-03-12  1:41   ` Derek M Jones
2008-03-12  2:20     ` Alexey Zaytsev
2008-03-12  4:28     ` Josh Triplett [this message]
2008-03-12 15:19       ` Neil Booth
2008-03-12 20:01         ` Josh Triplett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47D75C05.4090807@kernel.org \
    --to=josh@kernel.org \
    --cc=derek@knosof.co.uk \
    --cc=linux-sparse@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.