cocci.inria.fr archive mirror
 help / color / mirror / Atom feed
From: julia.lawall@lip6.fr (Julia Lawall)
To: cocci@systeme.lip6.fr
Subject: [Cocci] Coccinelle vs Firefox
Date: Sun, 17 Jul 2016 07:47:07 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.10.1607170737330.3253@hadrien> (raw)
In-Reply-To: <009C7972-C7EB-4B7F-ABC5-A1C0C1CA5797@mac.com>



On Sat, 16 Jul 2016, Perry Wagle wrote:

> Hi ?
>
> I need to comprehend the huge Firefox source, excise the bookmark
> subsystem, turn it into an extension, hack on the extension to bring
> back the functionality I need, and drop in the new extension.  Then, I
> just need to replace the whole thing with something far more advanced
> than the toy they want to turn it into.
>
> My workflow depends on bookmark tags working thus and so, and I
> anticipate that this yak shaving expedition will take me a year (since I
> want to develop tools to do it for me, instead of brute forcing it,
> which my ag?d brain doesn?t handle any more for programs of this size).
> One of those tools involves my bookmark tags thing, so its a
> bootstrapping thing too (fun!).
>
> So my question is whether you guys think Coccinelle would be useful to
> me in comprehending and doing MASS transformations of the firefox
> source?  I get the impression from lightly skimming that you concentrate
> on what I would describe as point fixes, which doesn?t seem the same.
> But this couldn?t be it all, else you wouldn?t be interested?
>
> The main problem is that firefox is written in a variety of programming
> languages.  How hard would it be to retarget Coccinelle to those
> languages?  And how useful for finding excision point for removing the
> existing bookmarks subsystem might it be?

Coccinelle was originally designed for doing collateral evolutions.  Ie,
an interface changes, so how to automate the updating of the users of the
interface.  But it relies on the user to know what needs to be done.
There has been a little work on inferring changes from examples (spdiff,
http://www.diku.dk/~jespera/), but this tends to run "forever" on complex
cases, and anyway the user still needs to know what to do to make the
examples in the first place.

Coccinelle makes some effort to maintain type information, so it can be
useful for things like finding out where is the function in the probe
field of the platform_driver structure actually called.

If you want to know how a pair of functions is used together, then
Coccinelle could be useful in searching for such uses.  This could be
useful for counting how often a function is used when a lock is or is not
held, to decide whether locking is needed.

But I don't think that Coccinelle would be useful as the main tool in a
code understanding project.  It is more useful when you know what you want
to do, but don't want to go through and do it everywhere by hand.

Coccinelle only works for C, and the part of C++ code that looks pretty
much like C.  The implementation is based on an AST that is specific to C,
so retargeting it for java, python, javascript, ruby, perl, whatever would
probably require quite a bit of work.

julia

> At this point, I?m just trying to determine what order to do things in,
> and where learning Coccinelle fits in, if at all.
>
> Is this enough information for you all to give me an idea, from 20,000
> feet, of whether Coccinelle makes sense for me or not?  If not, I?ll
> return in a week with more details.
>
> Thanks!
>
> ? Perry
>
> _______________________________________________
> Cocci mailing list
> Cocci at systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>

  reply	other threads:[~2016-07-17  5:47 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-17  2:12 [Cocci] Coccinelle vs Firefox Perry Wagle
2016-07-17  5:47 ` Julia Lawall [this message]
2016-07-17 22:44   ` Perry Wagle
2016-07-18  2:05     ` Perry Wagle
2016-07-18  5:11     ` Julia Lawall
2016-07-18 11:34       ` Perry Wagle
2016-07-18 15:39         ` Julia Lawall
2016-07-18 23:17           ` Perry Wagle
2016-07-18 15:57         ` SF Markus Elfring
2016-07-18 23:26           ` Perry Wagle
2016-07-18 16:19         ` [Cocci] Object-orientation with SmPL? SF Markus Elfring
2016-07-18 23:31           ` Perry Wagle
2016-07-17  6:48 ` [Cocci] Support for more programming languages? SF Markus Elfring
2016-07-18  0:43   ` Perry Wagle
2016-07-18 15:20     ` SF Markus Elfring
2016-07-18 23:39       ` Perry Wagle
2016-07-19  7:57         ` SF Markus Elfring
2016-07-17  7:14 ` [Cocci] Transformations for Firefox source files SF Markus Elfring
2016-07-18  0:50   ` Perry Wagle
2016-07-18 15:27     ` SF Markus Elfring

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=alpine.DEB.2.10.1607170737330.3253@hadrien \
    --to=julia.lawall@lip6.fr \
    --cc=cocci@systeme.lip6.fr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).