On 10 Jul 2010, n3...@mac.com wrote: > Overall I think the idea of extending splint to additional > non-pOSIX API's is perfectly sane and useful Static annotations > have a usage case, for automated QA testing, for detecting > mis-use of API's and more.
> But there are gonna be gotchas: push > 1) API's change in the "real world" push > 2) Manually applying annotations is quite a chore push > 3) the splint C parser has some issues still Finding which file had "parser pop 3) Yes. I hoped to extend the amount of code it can parse. I doubt it is every perfect in the presence of complex code constructs. Ie, deeply nested blocks, large code macros, etc. My hope was to fix some loose ends that people had noted and then maybe try to look more seriously about a gcc plugin that would support splint annotations... If someone hasn't already started in the mean time. pop 2) Yes. After annotation, however, it is quite easy to use. It is also generally faster as only the module under analysis has to be considered. Also, some of these annotations can actually be useful to code generators. Many splint annotations are similar to gcc attributes. Finally, I think that the annotations can be useful to a user to understand what the API is for. Currently splint lacks in verifying the correctness of some annotations. For instance, /*...@falsewhennull@*/ bool isEmpty(/*...@null@*/ char *p); verifies the caller but not the implementation. There are many reports of splint with SEGV. This is because an annotation like above is not consistent with the implementation (due to keep-going functionality added after the fact). Whole program (global checking) could be the future. However, it will only ever verify the current code base and not an ideal API. Only an annotation based solution can do that. Both need source code available. [insert proper tool for the job euphemism here]. I would guess that the static analysis tools of the future will do both. pop 1) I think that there are several parties interested in library API static analysis. This is really to speak to your first point. A library author would like to document the API and verify that the API is consistent with documentation and internal changes. A library user (a package) would like to know that the package works with various forms of the library. Finally, an end user (distribution vendors, security audits, etc) would like to verify that the entire base is consistent. I think this is what ISPRAS is doing. Mostly the concerns of the parties are similar. Having an splint annotated API is sort of like the formal LSB testing that ISPRAS is doing. If different versions of the library and dependant packages analyze cleanly with changes, they you have a good chance that no bugs have been introduced. This may be an internal change in the library, a change in the package, or both. If the API has changed, then a conditional (like STRICT in the splint system annotations) can be used to create splint specifications that are for multiple API versions. In many cases, API changes just add functionality so some prototypes, structures and enum values might be conditionalized in/out. This gives a package developer the chance for static analysis versus both API versions. Something an end user might not care about. > ISPRAS == Institute of System Programming, Russian Academy of Sciences > These are the people who are putting meat & muscle into LSB "standard" > interface testing. [snip] > With a little work at automation, and perhaps asking LSB or ISPRAS > to start generating splint files that Just Drop In automagically, > I think you have a very very sound approach to using splint > on OSS software. The dynamic testing tools are nice. I think that they have quite a bit in the way of dynamic security testing. I don't think they have data sanitization (SQL injection, relative path exploits, etc) automated in these tests. This is something that static analysis might do better with. Both static and dynamic tools are nice. Static tools will never test the compiler component. I think this is very important for C++ shared libraries. I hope something better comes along in the future. Splint works well for some means and not for others. Regards, Bill Pringlemeir. -- I never did give anybody hell. I just told the truth and they thought it was hell. - Harry S. Truman _______________________________________________ splint-discuss mailing list splint-discuss@mail.cs.virginia.edu http://www.cs.virginia.edu/mailman/listinfo/splint-discuss
