I am using splint for code checking, and it is throwing out a huge number of warnings. Some of them, I guess can be ignored. I am in the process of creating the .splintrc by trial and error.
My question,
Is there some sample .splintrc file that can be used?
I am using splint for C code, written for a multi-tasking embedded system.
This may not be the greatest of help but I think that you need to provide a bit more information about the type of error messages that you are getting and the target processor/compiler that you are using. The different compilers for embedded target processors all have their own syntax to provide their specific functionality (interrupt processing, transferring to supervisor modes and hardware interfacing are examples)
I have tried to use splint on the MSP430 under IAR and gave up because of the number of warnings and errors that it was throwing when it tried to process the compiler supplied hardware interface definition files. I bit the bullet and purchased Gimpel LINT which came with some configuration files that I could modify to support the precise flavour of compiler and processor I was using.
I have never worked with Splint, but have worked with PC-Lint, and this was my experience as well. Without the compiler configuration files, the lint tool will throw a ton of errors.
You will need to find or create compiler-specific configurations files for your compiler informing the linting tool of the special (non-standard) C constructs and macros that it uses which should be ignored by the linting tool, or you will continue to throw tons of errors.
It is worth the effort, however. Linting your code will help you find errors now instead of during testing when they are harder to find and much more expensive to fix.
Related
I am already setting the 3rd party code files as libraries in my project, but I am still getting messages from those files (libraries) in the Global Wrap-up in the PC Lint output file. Is there a way to suppress the messages from the libraries in the global wrap-up? I am using PC Lint v9.00
PC-Lint parses source files tagged as "library" the same way like normal source files but applies a different warning threshold. The option -w controls the warning threshold for normal files while -wlib controls the warning threshold for libraries. A typical setup would use -w3 for own code and -wlib(1) for library code.
With -wlib(1) PC-Lint still reports various major errors regarding library code, which is a good idea because these messages are often related to configuration errors of the PC-Lint project and not the library code itself.
Still it is quite common for 3rd party code to contain code that invokes PC-Lint warnings even at -wlib(1). In this case there are several solutions possible:
Turn off all warnings in Library code with -wlib(0). This might hide errors related to the project setup though.
Turn off the remaining library-related messages by using the option -elib(<x>) for each error code. In contrast to -e<x> using -elib<x> disables the error message for the library code only.
I would like to recommend the second solution unless you have to cope with a really high number of messages.
When we compile a C/C++ project, some files and codes in the project source are not needed for compilation. For example, test folder (some testing scripts), examples folder and dead code. How can I recognize these source files that are not compiled to binary files? It is not hoped that compiling is necessary. Cause I need to process many projects automatically and it is really hard to compile all projects without manual operations.
I know compilation can delete dead code automatically, but in my situation I can not compile the whole project, and in the source, there are many other codes that are not involved in final compilation such as code in test folder, tools folder... I hope to detect these code, as for dead code, I know its hard to detect it by static analysis, so disregard it, just care about whole files and whole folders that are not compiled.
Why I want to do this?
I want to extract some features (strings, function call graph, int constants... ) to represent this project and compare this features with the same features extracted from binary files to see what differences are there. So, if I extract features from code in test folder and the code are not compiled in the final binary files. There will be a big error when comparing these features.
Dead code would often -but not always- be eliminated by the compiler, when you ask it to optimize (but removing all dead code automatically is impossible, since undecidable because of equivalence with the halting problem). Be aware of the as-if rule permitting the compiler to do such optimizations. So in practice you don't need to remove the corresponding source code.
Some industries have as a coding rule (e.g. in DO-178C) the requirement that dead source code is forbidden. Detecting that is extremely difficult and in general impossible (see e.g. Rice's theorem), so requires a lot of sophisticated static program analysis techniques and external code review and costs a big lot (e.g. increase the cost of software development by more than 30x).
Your build automation system (e.g. cmake or Makefile, etc...) might be (and usually is) Turing-complete; so even removing entirely useless C++ source files is an impossible task in general. Even the POSIX shell (used in commands to build your thing) is difficult to analyze (see the excellent Parsing Posix [S]hell talk by Yann Regis-Gianas at FOSDEM2018).
I inherited an old project that uses an Innovasic ia188em processor (previously AM188 from AMD). I will likely need to modify the code, and so will need to recompile. Unfortunately, I'm not sure which compiler was used previously (it compiled into a .hex file), and searching through the source code (and in particular the header files) doesn't seem to indicate it either.
I did see one program that could work, but I was wondering if anyone knew of any free programs that might do this. I saw some forums where people said they thought either an old Borland compiler or Bruce's C Compiler may work with 80188 chips (which I assume my chip falls under?), but nothing concrete. I failed to compile with Borland C++ 5 when I tried, though I admit I probably didn't have it set up correctly.
This is for an embedded board (i.e. no OS). I don't program too often, so my compiler knowledge is limited. I mostly just write simple C programs and compile with gcc under linux. Any help is appreciated.
Updated 10/8: I apologize, I was looking at both this code, and the PC side code that talks to the embedded board, and got mixed up. The code for the ia188em (embedded board) is actually C (not C++). Updated title to reflect that. I'm not sure if it makes a huge difference or not.
You'll need a 16 bit "real mode" x86 compiler. If your compiler is a DOS targeted compiler, you will need some means of generating a raw binary rather than than MS-DOS load module (.exe), this may be possible through linker options or may require a non-DOS linker.
Any build scripts or makefiles included with the project code might help you identifier the toolchain used, but the likelihood is that it is no longer available, and you'll need to source "antique software".
When I used to do this sort of thing (1985 -> 1990) I used the intel toolchain, now long obsolete and no longer available from intel. The tools required were
iC-86 - The compiler
link-86 - the linker
loc-86 - the image locater.
There is some information on these tools at a very old site here.
Another method that was used at the time was to process the .exe file produced by a Microsoft standard real mode PC compiler (MS-Pascal was the language used on that project) into an absolutely located image that could be blown into EPROM. The tool used for the conversion was proprietary to the company so I have no idea whether there is an equivalent available
When I link to the one under Release/ ,got a fatal error:
LINK : fatal error LNK1146: no argument specified with option '/machine:'
Then I tried to link to the .lib under Debug/ and this time it works.
But what can be different?
Usually, no optimization is done to debug assemblies, while release assemblies are optimized. Debug assemblies will also often contain cruft like source file line numbers.
This isn't actually a C question; it relates to the platforms used.
Frequently, a project/solution will be set up to create a version for debugging and one for release, and putting them in Debug/ and Release/ directories is a common way to distinguish. The debug version will typically compile fast and run slowly, and contain information to link the internal execution to the source code (such as line numbers and variable names). The release version is typically slower to compile and faster to run, and it's much more difficult to track what's going on inside.
Obviously, there have to be differences between the debug and release versions, if only the appropriate compiler flags. However, in the build systems I'm familiar with, it's possible to make arbitrary other changes, and sometimes this will cause a release-version-only bug, which is a pain. Alternately, if the C code doesn't specify the behavior properly, the debug and release versions might interpret it differently, and that's also a pain.
In this case, I'd guess that there was a difference in how they were built. I can't really comment further without more information.
What is the OS? What is the C compiler used? What build system do you use (if you're using an IDE, possibly the one standard with the IDE)? What is the library you're using. Does your organization build it, or do you get it from outside? Knowing these things would give us a clue as to where to start looking.
You may want to change the build configuration for debug and release versions seperately.
Which static code analyzer (if any) do you use? I've been using PyLint for Python and I'm pretty satisfied with it, now I need something similar for C code.
How much of it's output do you have to suppress for normal daily usage?
Wikipedia maintains a list of static code analysis tools for various languages (including C).
Personally, I have used both PC-Lint and Splint. The best choice depends on the type of application you have written. However no matter which tool you use, there will be a low signal to noise ratio until you properly tune the tool and your code.
PC-Lint is the most powerful Lint tool I used. If you add it to an existing project, the signal to noise ratio can be low. However, once the tool and your code are properly configured, it can be used as part of your standard build process. The last major project where I used it, we set it so that PC-Lint warnings would break the build. Licenses for PC-Lint cost $389, but it is worth the cost.
Splint is a great open-source tool. I have used it on several projects, but found that it can be difficult to configure when using a compiler with non-ANSI C extenstions (e.g. on embedded systems projects).
Valgrind is also worth considering as a dynamic analysis tool.
You specifically requested feedback on SourceMonitor. This tool provides interesting metrics on your code, but should be used as a supplement to good Lint tool as it does not provide that kind of analysis.
As stated on their home page, SourceMonitor will:
...find out how much code you have and
to identify the relative complexity of
your modules. For example, you can use
SourceMonitor to identify the code
that is most likely to contain defects
and thus warrants formal review.
I used it on a recent project and found it to be easy to use (even for embedded systems code). The complexity metric is an excellent resource for developing code that will be less error-prone and easier to maintain.
SourceMonitor provides nice graphs of its output as well as well-formatted XML if you want to automate metrics collection. The only downside is that the tool only runs on Windows.
We use PC-Lint and are very happy with it.
There seem to be a few camps regarding message suppression and tuning:
suppress everything, then unsuppress only what you're interested in
unsuppress everything, then suppress warnings you're not interested in
keep everything unsuppressed
We tend to fall somewhere between the second and third categories. This does mean a ludicrous 100MiB+ text dump (one error per line) per lint run across the core libraries (lots of old code).
A custom diff-like tool watches for changes and emails those out to the commit's author, which keeps the amount that most people have to look at down to a few lines. We gather interesting statistics about errors-over-time with some basic data mining.
You can get really polished here, hyperlinking the errors back to more detailed descriptions, providing "points" for fixing existing warnings, etc...
There's splint, although, to be honest, I've never been able to get it to work; on my platform, it really is too overactive. In practice, my most-used "lint" are the following warning flags for gcc
-std=c89 -pedantic -W -Wall -Wstrict-prototypes -Wunreachable-code -Wwrite-strings -Wpointer-arith -Wbad-function-cast -Wcast-align -Wcast-qual
Of course, I've mostly forgotten what half of them mean. But they catch quite a few things.
I'm a big fan of David Evans's work on LC/Lint, which has apparently had its name changed to Splint. It is very aggressive, and you can tell it a lot of useful information by adding annotations to your code. It is designed to be used with programmer annotations. It will function without them, but if you try to use it as a simple checker without providing any annotations, you will probably be disappointed. If what you want is totally automated checking, and if you can deal with a Windows-only tool, you're better off with Gimpel's PC-Lint. Jim Gimpel has had happy customers for over 25 years.
I used PCLint forever and really liked it. I wish they'd get into C#... They are the ones with the pop quizzes on C or C++ code in all the magazines.
There is one in the llvm clang project http://clang-analyzer.llvm.org . I have not tried it myself but i intend to do it.
It looks pretty good in action:
http://www.mikeash.com/?page=pyblog/friday-qa-2009-03-06-using-the-clang-static-analyzer.html
Above is for Objective-C but it should be the same for C.