Lint

The only free one known to me is splint. C only, no C++.

If you value your time, then the Gimpel product, PC-Lint is worth the $389 for a single user license. Buy it.

Bob

Absolutely.

Oliver

In message , ashu writes

Nothing 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.

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). 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.

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.

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. gcc with all its warnings will detect a large percentage of typical typo mistakes and other common errors. 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.

Actually, the biggest advantage I found with PC-Lint was not that it detected errors (although it does do that) but that it helps instill better techniques. Sort of a mini rapid code review.

Robert

This is true

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.

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

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

This is true. So using a coding standard such as MISRA-C will help.

As will any other compiler. However GCC has well known problems like incorrectly handling volatile...

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.

In message , Robert Adsett writes

I have found this too. Programmers get pissed off having to do corrections so they write the code to pass the static checker. It is a learnt behaviour :-)

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!).

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).

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.

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 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.

I have no idea what is the diffrence between free (speech) and free (beer) software? How do you exaplin to a board of directors that we need to send a box of beer to someone on the internet to get the engineering department tools working better?

Untrue

Also untrue, they have just got improved through a process of use and feedback

The word "free" in English has two meanings. It can mean zero cost price (as in "free beer"), and it can mean unrestricted (as in "free speech"). If you download a zero cost demo version of some software, it is "free as in beer" because you did not pay any money for it. If you download software that comes with full source code and a license allowing you to modify the source and use and distribute the software in many different ways (the details depending on the license), then it is "free as in speech" software. These are very different concepts.

"Free software" and "open source software" are related terms, and often joined as "Free and open source software" (or FOSS). "Free" places more emphasis on it being morally, ethically or philosophically "better" for software to be free, while "open source" places more emphasis on the pragmatic advantages of an open development process.

You don't know what "free software" means yet you feel qualified to counter a long argument with a single unsubstantiated word?

In message , David Brown writes

Yet professional companies can show a 30% saving on project times using static analysis on REAL projects.

However the motives for OS development sponsors may nor may not have any bearing on this. They usually have more political than engineering reasons for supporting FOSS. They are usually funding FOSS out of the marketing budget as an aid to sell hardware.

I know several companies that supposedly "support" FOSS who only do it (and do the minimum) as a marketing ploy to sell something else and think that most FOSS people are either religious nutters or cheapstates

Professional companies can show 50% (actual figures are pulled out of the air, but you get the point) savings from using Ada instead of C, yet most use C or C++. They can save 40% from doing proper code reviews, but most don't. They can make more money in the long term by investing in good local developers, yet they outsource for short-term savings.

I don't mean that static error checkers are useless - just that they are not useful in all cases. The fact that the only serious open source C static error checker, splint, has stagnated in the past few years is a clear indication that such tools are not in heavy demand among open source developers. After all, such error checking software is not magic

- it would not cost IBM, etc., much to pay for its development if they wanted such software.

That's not political reasoning - it's economic reasoning. And for commercial companies, economic reasons are *always* the fundamental reasons for any decisions. A company like IBM supports, develops, and uses FOSS because it is good engineering practice (for many types of software, but by no means all), and that leads to higher quality products, giving a payback in hardware sales and service contracts.

If they think that, then they misunderstand FOSS. There is no doubt that there *are* "religious nutters" and "cheapskates" that support FOSS

- but there are such people in most communities. And the "religious nutters" in any community are often those that shout loudest. Successful corporate support of FOSS is not always easy to do - it means building and supporting a community of users and developers. The result of this is that you let others do much of your development - at the cost of less control.

Mine were from a study by Alcatel on their own projects and most certainly not pulled out of the air. .

And that has no bearing on the effectiveness of static analysis tools You talk as though what Open Source developers do is in some way an important barometer.

Why re-intent the wheel. You have the cart before the horse.

If you want real figures, you can look them up - I am entirely confident that you can find such studies with wide ranges of cost saving figures.

What open source developers do *is* an important barometer when talking about open source tools. The OP was hoping to find a free (cost) lint tool, and this branch of the thread is discussing why there are no major open source (and therefore free cost) static error checkers for C.

You re-invent the wheel when you can make a wheel that is better, cheaper, more flexible, or better suited for your own needs - or when you think you can make (or save) money from it.

An example of this is sparse, written specifically for checking the Linux kernel. It checks things that other tools such as PC-lint cannot, but is simpler and supports only what is needed.

I did find another tool that may be of interest to the OP, although I haven't tried it myself:

Which is why there are no decent open source static checkers.

... snip ...

And most of us know various firms that save 50% to 100% of software costs by using FOSS. Then there are also quite a few firms that publish FOSS and seem to make a reliable profit.

... snip ...

I think the problem there is familiarity. It doesn't take a major effort to find programmers acquainted (but not necessarily expert) in C or C++. It does take a major effort to find programmers acquainted with Ada, and even more to find real experts.