>> (For that matter, it'd be nice if Splint accepted *all* of C99, or at >> least all the common bits. Mixed statements and declarations certainly >> seem to be common in C99 code.) > >This would involve changing the parser, which is told to be >non-trivial. Maybe replacing the current parser with e.g. sparse would >be easier ...
>From the parts of the parser I saw while making that patch, I would guess the difficulty is not in parsing C correctly, but rather in making the right calls from the parser to make sure splint's internal data structures are built properly during the parsing. I would further guess that this does not get easier by using a different front-end. There are also some non-standard extensions that presumably would not be present in another front-end. It's not obvious to me how many there are, or how hard it would be to port their functionality into a new parser. There might be more, but the ones I think I saw were: 1. QNOTREACHED: I'm pretty sure it's not part of a normal C parser. It seems to be some kind of non-reachable code detection that's done inside the parser itself, rather than in post-processing of the parse structures. 2. There's some macro handling inside the parser which would ordinarily be expanded in a pre-processor. Depending how much more is necessary to get good c99 coverage, it might be significantly easier to continue patching the existing parser. I don't suppose anybody knows of a list of c99 constructs that splint does not support properly? Maybe it would be worth running through the gcc c-torture tests to get a first cut, but analyzing that is probably more time than I have today... _______________________________________________ splint-discuss mailing list splint-discuss@mail.cs.virginia.edu http://www.cs.virginia.edu/mailman/listinfo/splint-discuss
