Re: Lint
- From: David Brown <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 09 Mar 2009 09:51:01 +0100
Chris H wrote:
In message <rYmdnR8CE7FP2ynUnZ2dnUVZ8jyWnZ2d@xxxxxxxx>, David Brown <david.brown@xxxxxxxxxxxxxxxxxxxxxxxxxx> writesChris H wrote:In message <c5edf1c3-873a-4e6e-a735-98a35a99a0cc@xxxxxxxxxxxxxxxxxxxxxxxxxxx>, ashu <ashutosh.ghildiyal@xxxxxxxxx> writesNothing in this life is free. There are many versions of lint out there from "free" to expensive. However the free ones usually cost you a lot in time... time to reinvent the wheels that are already set up in the "more expensive" versions.
What is best "free" version of Lint around ? Or rather should ask,
what free version of Lint do you prefer ?
Time == money.
Best time/cost/performance lint I know of is Gimpel's PC-lint (which is why we distribute it in preference to any other)
Generally speaking, I'd disagree with you. Free, as in open source, will often take time to get full use of - and it may have hidden "costs" (such as license or support issues).
This is true
But the same applies to commercial software - I've seen absolutely no reason to assume that one piece of software is "better" than an alternative based purely on the cost price or the freedoms or restrictions in the licence.
I agree but the problem with most FOSS is there is usually more setting up to do and the support is a longer and less reliable. It is not a function of cost but the whole way it works.
Again without going into specifics, I've seen expensive commercial software with terrible support, and totally free (beer and speech) software with excellent free support. And I've seen the opposite too. What I know for sure is that you cannot generalise - there are *no* trends or biases that are applicable across more than very small niches. The only generalisation that tends to be valid is that if you are paying a company specifically for support, rather than software plus support, you are going to get at least reasonable quality support (if they plan to stay in business!).
There is a lot of free software that is not FOSS also there is a lot of software that has a licence that is more restrictive than FOSS
You don't get free (speech) software that is not also open - that comes from the definitions (look up the terms on wikipedia). You certainly get free (beer) software that is not open. And there are wide ranges of licenses for both open source and closed source, with all sorts of restrictions and freedoms, the effects of which vary widely according to your use of the software.
It all boils down to having to consider each major piece of software individually, and balance the costs (such as price tags and time) against the value, according to how *you* are going to use it. You can't make any assumptions, and the balance will be different from user to user (even within the same company).
However, in the case of static error detection in C code, there is currently only one good general-purpose tool - Gimpel's PC-lint. There is the free splint, which is better for some sorts of development processes, but for most uses PC-lint will be a better choice.
Part of the reason is that PC-lint has been developed by people very close to the language development and it has some 80 pre set compiler configurations along with many IDE set-ups and filters for things like MISRA-C and Dan Saks recommendations
The flip side of the coin is that no major open source development sponsor has seen serious advantage in general use static error checkers. Existing projects are almost entirely academic, and academic projects often flounder and bit-rot after the initial developers have moved on (splint is a working product as it stands, but has had very little development in recent years). If such software of significant interest to large open-source-friendly software companies like IBM, Intel, Red Hat, or Google, then we would have seen either alternatives to splint, or heavy investment in splint development. This is often simple economics - it is cheaper for such companies to develop open source software than to invest in large numbers of commercial licenses.
I think much of this lack of interest in lint tools comes from a combination of reasons. One is a growing belief that C is unsuitable for large software projects - languages like Java or C++, or higher level languages like Python, let you avoid many of the typical errors found by such tools by having better memory management, proper strings, and so on.
Secondly, C compilers do much better static error checking than they used to as a side effect of better optimisation - while figuring out things like aliasing, variable lifetimes, and ideal memory organisation, a compiler can often spot buffer overflows and other such errors. Common typos (like "if (x = 1)...") are easily spotted and warned by a good compiler. gcc will also happily check for mistakes in printf format strings, missing checks for failed malloc(), etc.
Thirdly, to get the best out of these sorts of tools, you often have to add extra comments in special formats. For example, split will let you augment a type or variable declaration with a special comment giving its range, and it can then use that for range checking later. This sort of thing can give very powerful checking, but the cost is that your source becomes an ugly hybrid language. If you need that sort of feature, you are probably better off using a language such as Ada that lets you express such restraints in the language itself.
Finally, automated test suites, if written and used correctly, can do most of this checking (at least, the functional checks - not style checks) and more.
I'm not saying that there is no need for pc-lint and similar tools - just that they are not necessary for all types of development.
Of course, doing careful development, following sensible embedded development style rules (such as avoiding dynamic memory, avoiding unnecessary pointers, tc.) will get you far further than any static error checker.
This is true. So using a coding standard such as MISRA-C will help.
Except that parts of MISRA-C are downright horrible.
Seriously, I agree of course.
As long as the standard you use is not MISRA-C... :-)
gcc with all its warnings will detect a large percentage of typical typo mistakes and other common errors.
As will any other compiler. However GCC has well known problems like incorrectly handling volatile...
gcc handles *sensible* volatile usage perfectly well in every case that I have tried (and I've used a lot of versions for a lot of targets). According to a recent report, pretty much *no* compiler handles volatile properly in every case.
Anyway, there is nothing wrong with combining gcc and other tools. When I've used other compilers, I often set up my makefile to run the code through gcc (the target doesn't matter, though it helps if the int width is the same) for error checking and to set up makefiles automatically.
So you should be asking yourself if you can find a way to write better code in the first place, rather than relying on a tool to help find the bugs later.
You need to do both. Use a good coding standard and use static analysis to test. I have found that after a while apart from the usual typos the use of static analysis does improve code. After a while people tend to automatically write code that will pass the static checker.
.
- Follow-Ups:
- References:
- Prev by Date: Re: How do i interface with the processor and acheive 10 Mbps?
- Next by Date: Re: Filter needed based on destination MAC address
- Previous by thread: Re: Lint
- Next by thread: Re: Lint
- Index(es):
Relevant Pages
|
