On Wed, 2009-05-13 14:43:54 +0530, Vijayendra Suman wrote: > [..] > - The code base is very big and so not all code paths will be executed > even if my H/W is ready in next 1-2 weeks, so valgrind will only help in > the > control path of executed code.
Hi Vijayendra, I wouldn't focus too much on checking third-party code for my own projects (given they are proven to be portable and widespread as it is the case for glibc). I am sure the maintainers of the libraries in question do a better job in running tests on or doing reviews for their own code. Both, static and run-time code analysis, need deep knowledge of the code under test, as you'll have to correctly annotate the sources for a meaningful static code analysis and you have to run the library under valgrind with reasonable test programs. If you just want to _use_ the libraries in question (in contrast to working on them), focus on your own code instead and try to use the third-party libraries the same way as most others do, in order to hit the code paths best tested. (Provided, of course, your project is not safety-related. Otherwise, you'd have to avoid third-party code as much as possible. For safety-related software, I even don't use standard libc functions such as memcpy()). Ludolf (who is sorry about this thread somehow triggered his "do tests you fully understand only" statement) -- --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Floßwörthstraße 41 e-mail: lholzh...@bihl-wiedemann.de D-68199 Mannheim, Germany --------------------------------------------------------------- _______________________________________________ splint-discuss mailing list splint-discuss@mail.cs.virginia.edu http://www.cs.virginia.edu/mailman/listinfo/splint-discuss
