xref: /illumos-gate/usr/src/tools/smatch/src/FAQ (revision 1f5207b7)
1	FAQ - Why sparse?
2
3Q.  Why not just use gcc?
4
5A.  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 of 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
20Q.  Why not GPL?
21
22A.  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
46Q.  Does it really parse C?
47
48A.  Yeah, well...  It parses a fairly complete subset of "extended C" as
49    defined by gcc.  HOWEVER, since I don't believe in K&R syntax for
50    function declarations or in giving automatic integer types, it
51    doesn't do that.  If you don't give types to your variables, they
52    won't have any types, and you can't use them.
53
54    Similarly, it will be very unhappy about undeclared functions,
55    rather than just assuming they have type "int".
56
57    Note that a large rationale for me doing this project is for type
58    following, which to some degree explains why the thing is type-anal
59    and refuses to touch the old-style pre-ANSI non-typed (or weakly
60    typed) constructs. Maybe somebody else who is working on projects
61    where pre-ANSI C makes sense might be more inclined to care about
62    ancient C.  It's open source, after all. Go wild.
63
64
65Q.  What other sparse resources are available?
66
67A.  Wiki: http://sparse.wiki.kernel.org/index.php/Main_Page
68
69    Mailing list: linux-sparse@vger.kernel.org
70    See http://vger.kernel.org/vger-lists.html#linux-sparse for subscription
71    instructions and links to archives
72
73    Git repo: git://git.kernel.org/pub/scm/devel/sparse/sparse.git
74    gitweb: http://git.kernel.org/?p=devel/sparse/sparse.git
75