FAQ

   1         FAQ - Why sparse?
   2
   3 Q.  Why not just use gcc?
   4
   5 A.  Gcc is big, complex, and the gcc maintainers are not interested in
   6     other uses of the gcc front-end.  In fact, gcc has explicitly
   7     resisted splitting up the front and back ends and having some common
   8     intermediate language because or religious license issues - you can
   9     have multiple front ends and back ends, but they all have to be part
  10     of gcc and licensed under the GPL.
  11
  12     This all (in my opinion) makes gcc development harder than it should
  13     be, and makes the end result very ungainly.  With "sparse", the
  14     front-end is very explicitly separated into its own independent
  15     project, and is totally independent from the users.  I don't want to
  16     know what you do in the back-end, because I don't think I _should_
  17     know or care.
  18
  19
  20 Q.  Why not GPL?
  21
  22 A.  See the previous question: I personally think that the front end
  23     must be a totally separate project from the back end: any other
  24     approach just leads to insanity.  However, at the same time clearly
  25     we cannot write intermediate files etc crud (since then the back end
  26     would have to re-parse the whole thing and would have to have its
  27     own front end and just do a lot of things that do not make any sense
  28     from a technical standpoint).
  29
  30     I like the GPL, but as rms says, "Linus is just an engineer". I
  31     refuse to use a license if that license causes bad engineering
  32     decisions.  I want the front-end to be considered a separate
  33     project, yet the GPL considers the required linking to make the
  34     combined thing a derived work. Which is against the whole point
  35     of 'sparse'.
  36
  37     I'm not interested in code generation. I'm not interested in what
  38     other people do with their back-ends.  I _am_ interested in making a
  39     good front-end, and "good" means that people find it usable. And
  40     they shouldn't be scared away by politics or licenses. If they want
  41     to make their back-end be BSD/MIT licensed, that's great. And if
  42     they want to have a proprietary back-end, that's ok by me too. It's
  43     their loss, not mine.
  44
  45     At the same time, I'm a big believer in "quid pro quo". I wrote the
  46     front-end, and if you make improvements to the semantic parsing part
  47     (as opposed to just using the resulting parse tree), you'd better
  48     cough up.  The front-end is intended to be an open-source project in
  49     its own right, and if you improve the front end, you must give those
  50     improvements back. That's your "quid" to my "quo".
  51
  52
  53 Q.  So what _is_ the license?
  54
  55 A.  I don't know yet.  I originally thought it would be LGPL, but I'm
  56     possibly going for a license that is _not_ subsumable by the GPL.
  57     In other words, I don't want to see a GPL'd project suck in the
  58     LGPL'd front-end, and then make changes to the front end under the
  59     GPL (this is something that the LGPL expressly allows, and see the
  60     previous question for why I think it's the _only_ thing that I will
  61     not allow).
  62
  63     The current front-runner is the OSL ("Open Software License", see
  64     http://www.opensource.org/licenses/osl.php), together with a note on
  65     what makes source derivative and what does not to make it clear that
  66     people can write back-ends for it without having to make those
  67     back-ends available under the OSL.
  68
  69
  70 Q.  Does it really parse C?
  71
  72 A.  Yeah, well...  It parses a fairly complete subset of "extended C" as
  73     defined by gcc.  HOWEVER, since I don't believe in K&R syntax for
  74     function declarations or in giving automatic integer types, it
  75     doesn't do that.  If you don't give types to your variables, they
  76     won't have any types, and you can't use them.
  77
  78     Similarly, it will be very unhappy about undeclared functions,
  79     rather than just assuming they have type "int".
  80
  81     Note that a large rationale for me doing this project is for type
  82     following, which to some degree explains why the thing is type-anal
  83     and refuses to touch the old-style pre-ANSI non-typed (or weakly
  84     typed) constructs. Maybe somebody else who is working on projects
  85     where pre-ANSI C makes sense might be more inclined to care about
  86     ancient C.  It's open source, after all. Go wild.
  87
  88
  89 Q.  What other sparse resources are available?
  90
  91 A.  Mailing list:  linux-sparse@vger.kernel.org
  92     (email majordomo@vger.kernel.org to subscribe)
  93
  94     Git repository:  devel/sparse/sparse.git under http://kernel.org/git/
  95     BitKeeper repository:  bk://sparse.bkbits.net/sparse
  96