1*1f5207b7SJohn Levon FAQ - Why sparse? 2*1f5207b7SJohn Levon 3*1f5207b7SJohn LevonQ. Why not just use gcc? 4*1f5207b7SJohn Levon 5*1f5207b7SJohn LevonA. Gcc is big, complex, and the gcc maintainers are not interested in 6*1f5207b7SJohn Levon other uses of the gcc front-end. In fact, gcc has explicitly 7*1f5207b7SJohn Levon resisted splitting up the front and back ends and having some common 8*1f5207b7SJohn Levon intermediate language because of religious license issues - you can 9*1f5207b7SJohn Levon have multiple front ends and back ends, but they all have to be part 10*1f5207b7SJohn Levon of gcc and licensed under the GPL. 11*1f5207b7SJohn Levon 12*1f5207b7SJohn Levon This all (in my opinion) makes gcc development harder than it should 13*1f5207b7SJohn Levon be, and makes the end result very ungainly. With "sparse", the 14*1f5207b7SJohn Levon front-end is very explicitly separated into its own independent 15*1f5207b7SJohn Levon project, and is totally independent from the users. I don't want to 16*1f5207b7SJohn Levon know what you do in the back-end, because I don't think I _should_ 17*1f5207b7SJohn Levon know or care. 18*1f5207b7SJohn Levon 19*1f5207b7SJohn Levon 20*1f5207b7SJohn LevonQ. Why not GPL? 21*1f5207b7SJohn Levon 22*1f5207b7SJohn LevonA. See the previous question: I personally think that the front end 23*1f5207b7SJohn Levon must be a totally separate project from the back end: any other 24*1f5207b7SJohn Levon approach just leads to insanity. However, at the same time clearly 25*1f5207b7SJohn Levon we cannot write intermediate files etc crud (since then the back end 26*1f5207b7SJohn Levon would have to re-parse the whole thing and would have to have its 27*1f5207b7SJohn Levon own front end and just do a lot of things that do not make any sense 28*1f5207b7SJohn Levon from a technical standpoint). 29*1f5207b7SJohn Levon 30*1f5207b7SJohn Levon I like the GPL, but as rms says, "Linus is just an engineer". I 31*1f5207b7SJohn Levon refuse to use a license if that license causes bad engineering 32*1f5207b7SJohn Levon decisions. I want the front-end to be considered a separate 33*1f5207b7SJohn Levon project, yet the GPL considers the required linking to make the 34*1f5207b7SJohn Levon combined thing a derived work. Which is against the whole point 35*1f5207b7SJohn Levon of 'sparse'. 36*1f5207b7SJohn Levon 37*1f5207b7SJohn Levon I'm not interested in code generation. I'm not interested in what 38*1f5207b7SJohn Levon other people do with their back-ends. I _am_ interested in making a 39*1f5207b7SJohn Levon good front-end, and "good" means that people find it usable. And 40*1f5207b7SJohn Levon they shouldn't be scared away by politics or licenses. If they want 41*1f5207b7SJohn Levon to make their back-end be BSD/MIT licensed, that's great. And if 42*1f5207b7SJohn Levon they want to have a proprietary back-end, that's ok by me too. It's 43*1f5207b7SJohn Levon their loss, not mine. 44*1f5207b7SJohn Levon 45*1f5207b7SJohn Levon 46*1f5207b7SJohn LevonQ. Does it really parse C? 47*1f5207b7SJohn Levon 48*1f5207b7SJohn LevonA. Yeah, well... It parses a fairly complete subset of "extended C" as 49*1f5207b7SJohn Levon defined by gcc. HOWEVER, since I don't believe in K&R syntax for 50*1f5207b7SJohn Levon function declarations or in giving automatic integer types, it 51*1f5207b7SJohn Levon doesn't do that. If you don't give types to your variables, they 52*1f5207b7SJohn Levon won't have any types, and you can't use them. 53*1f5207b7SJohn Levon 54*1f5207b7SJohn Levon Similarly, it will be very unhappy about undeclared functions, 55*1f5207b7SJohn Levon rather than just assuming they have type "int". 56*1f5207b7SJohn Levon 57*1f5207b7SJohn Levon Note that a large rationale for me doing this project is for type 58*1f5207b7SJohn Levon following, which to some degree explains why the thing is type-anal 59*1f5207b7SJohn Levon and refuses to touch the old-style pre-ANSI non-typed (or weakly 60*1f5207b7SJohn Levon typed) constructs. Maybe somebody else who is working on projects 61*1f5207b7SJohn Levon where pre-ANSI C makes sense might be more inclined to care about 62*1f5207b7SJohn Levon ancient C. It's open source, after all. Go wild. 63*1f5207b7SJohn Levon 64*1f5207b7SJohn Levon 65*1f5207b7SJohn LevonQ. What other sparse resources are available? 66*1f5207b7SJohn Levon 67*1f5207b7SJohn LevonA. Wiki: http://sparse.wiki.kernel.org/index.php/Main_Page 68*1f5207b7SJohn Levon 69*1f5207b7SJohn Levon Mailing list: linux-sparse@vger.kernel.org 70*1f5207b7SJohn Levon See http://vger.kernel.org/vger-lists.html#linux-sparse for subscription 71*1f5207b7SJohn Levon instructions and links to archives 72*1f5207b7SJohn Levon 73*1f5207b7SJohn Levon Git repo: git://git.kernel.org/pub/scm/devel/sparse/sparse.git 74*1f5207b7SJohn Levon gitweb: http://git.kernel.org/?p=devel/sparse/sparse.git 75