What is the difference between Splint and LCLint?
Before 2002, Splint was known as LCLint. Splint 3.0 is the successor to LCLint 2.5.
LCLint was originally named for LCL, the Larch C Interface Language and lint, a well-known C program checking tool. Because our tool has diverged from LCL, and our focus now is on secure programming, it was renamed Splint. Splint's name has (at least) three interpretations: specifications lint, secure programming lint, and first aid for programmers. It's also easier to pronounce than LCLint.
Thomas Jefferson's Serpentine Walls at the University of Virginia. The walls are one brick thick, but because of their design are both strong and aesthetic. Like a secure program, secure walls depend on sturdy bricks, solid construction, and elegant and principled design.
Can I include Splint in my software distribution?
Yes. Splint is licensed under the GNU General Public License. You may redistribute it as you wish so long as credits and pointers to www.splint.org are not changed or removed. Splint may be included in commercial distributions, and is included in several Linux and freeware CDs. If you redistribute Splint, please let us know by sending a message to splint@cs.virginia.edu.
Can we use your software in our company? (We are not a GNU organization.)
Yes, splint is GPL-licensed. Anyone may use it. If you want to redistribute it, check the license for details or contact us.
Which compilers does Splint support?
Splint is independent from your compiler. It should be able to handle code written for any compiler as long as the code is C99 compliant.
No. Splint handles ISO C99 (and some gcc extensions if +gnuextensions is used). We don't have the resources (or the research justification) to build a C++ front end, but if you are interested in building a C++ front end the source code is available, and I will certainly be willing to help.
Check to see if there is GNU tar on your system, it is usually invoked by the command gtar or gnutar. GNU tar supports the -z option.
You can also unzip the file then untar it. Do: gunzip filename.tar.gz to unzip then tar -xvf filename.tar
I want to use Splint in Windows. How do I do that?
See http://splint.org/win32.html for instructions on obtaining and installing Splint on Windows.
I have installed Splint for Windows 2000. Where should I put the ".splintrc" file?
For Win32, Splint looks for splint.rc instead of .splintrc due to the DOS filename problems. It will look first in the current directory, then in your home directory. See the Splint manual for more information.
When I build Splint I get the following error:
Checking for...
Checking manual...
cmx > / Checking tests2.2...
Checking tests2.4...
Checking tests2.5...
Checking db1...
0a1,2
> /cmx/tools/make -e clean
> /cmx/tools/make -e check
*** FAIL ***
Checking db2...
0a1,/tools/make -e clean
> /cmx/tools/make -e check
*** FAIL ***
Checking db3...
Should I be worried?
Those diffs look harmless. It is likely that your make is set up slightly differently than ours.
One possibility is that the installation directory where the test suite is running is on the system path (hence, splint won't report errors if -sysdirerrors is set, as it is by default). Try adding +sysdirerrors to the command line for the test suite to see if that is the problem, or installing Splint in a different directory not in the system path.
Usually not.
Parse errors usually occur in code written for compilers that use nonstandard keywords. (See the question on using Splint for code development on embedded systems.)
If you're getting parse errors make sure that the required libraries are included by using the +posixlib or +unixlib flags. If you're using nonstandard gnu extensions the +gnuextensions flag make be helpful.
However, Splint doesn't yet support all C99 extensions so there are some legitimate C programs that will need to be modified.
I heard that Splint can generate some spurious errors ( not genuine errors). Is it correct ?
Yes. Many of the program properties that Splint checks are undecidable. This means that any static analysis tool that can be run on real programs will either produce false positives or false negatives. Because of this and to improve efficiency, Splint makes some simplifying assumptions. This means that Splint will occasionally produce spurious warnings or miss real errors.
However, often spurious errors can be fixed by adding additional annotations.
Splint doesn't interpret const (at all). See the manual section on modifies checking (http://www.splint.org/manual/html/sec7.html).
You can often use -D to solve this problem.
If you just want to ignore a keyword, you can add -Dnonstandardkeyword= to make the preprocessor eliminate the keyword, where nonstandardkeyword is the name of the keyword. Similarly, you can use -Dspecialtype=int to make a custom type parse as an int.
You can use -I to set the include path like you would with a compiler.
I use realloc in my code. How can I get Splint in check this code more effectively?
realloc has complicated semantics that make it difficult to use correctly. Make sure that you understand realloc and that you really need to use it.
If you decide to use realloc, we recommend that you wrapper it. The document Using Wrapper Functions explains how to do this. That document is included in the Splint documentation and is also available at:
There are lots of things that the C spec allows and defines clearly, that Splint will provide warnings for. It's not a question of it being "wrong", it's a matter of it being likely to reveal a programming mistake.
The C standard says that what I'm doing is okay. Why does Splint give me a warning?
See the previous question.
Splint complains if I ignore the return value of scanf but not printf?
This is just a strategic decision --- we view ignoring the result of a scanf to be more likely to reveal a problem with the code than ignoring the result of a printf, even though strict programmers will want to check printf also.
If you want stricter checking, use the flags +ansistrictlib, +posixstrictlib, +unixstrictlib to select the strict versions of these libraries.
Sorry, Splint does not yet support variadic macros. We hope to fix this in a future release.
I think I've found a bug in Splint. What should I do?
See http://www.splint.org/bugs.html for a list of known bugs and instructions on reporting bugs.
Splint tells me that there is a bug and I should report it. What information should I send?
Ideally we would like enough code to reproduce the problem. Small snippets of code which trigger the bug are the best but more code is also acceptable.
If we're not able to reproduce the problem, then we are unlikely to be able to patch Splint. However, we would still appreciate hearing about the bug and may be able to at least to offer you advice on working around the problem.
My question isn't answered here. How can I get more information about Splint?
First check the Splint manual and the mailing list archives.
The Splint manual is available at: http://www.splint.org/manual/
The mailing list archives are at:
http://www.mail-archive.com/lclint-interest%40virginia.edu/
If you're still unable to find the information to answer your question, you can try posting the question to the splint-discuss mailing list (see http://www.splint.org/lists.html)
You can also email us at splint@splint.org.