Static code analysis

[jwdietrich]

Are there any tools for static code analysis available that support Free Pascal sources?

There are some for Delphi projects but I didn't find one that claims to support FPC. Who has experience with using these tools for Free Pascal code? Even better would be a dedicated tool that also supports testing complete Lazarus projects.

[marcov]

There are some for Delphi projects but I didn't find one that claims to support FPC. Who has experience with using these tools for Free Pascal code? Even better would be a dedicated tool that also supports testing complete Lazarus projects.

I used Peganza in the past because my previous employer had a license. It was nice, but not maintained. IIRC it is already unusable with D2006 constructs.

I must have Castalia somewhere (packaged with some Delphi), but it seemed slow etc, so I didn't install it the second time. I prefer separate tools to IDE Integration anyway.

[skalogryz]

hmm... interesting.

2: jwdietrich are you planning to create a wiki page about it?
Peganza seems to be maintained (last updates the second half of 2014)
Castailia seems to be open source

[skalogryz]

a crystal ball suggests that FPC syntax is not supported. fpc-passsrc is recommended for the update and usage

[jwdietrich]

Thanks four your answers. I will give your suggestions a try.

@skalogryz: Well, I first want to improve my own code. Some of my projects are for medical application and therefore safety is an important concern. I want to adopt NASA’s 10 rules for developing safety-critical code, which requires static code analysis.  If this works and I have gained enough experience I am also willing to write a wiki article.

[skalogryz]

yay! found it! Rule #8 (preprocessor) doesn't apply to Pascal at all.

Rule #7 (do not treat functions as procedures) is a bit odd. Since satisfying the rule, might cause violation in Rule #1 (complex/spaghetti code) and eventually Rule #4 (short function listing). I guess it suggests - if you have a function, that you need to treat like a procedure - write a wrapping procedure for it and use it. Which logically doesn't make much sense, since the return value is ignored anyway. On the brighter side, the comment of "why to ignore the return value" could be kept in one place.

Rule #3, is kinda questionable. Since pretty much anything is on the heap these days. Allocating and reallocating (whenever needed or not) in run-time. On the other hand, most of dynamic memory management is handled by the compiler, if developers are corresponding types: dynamic arrays, classes etc.. instead of using good-old pointers.

But for the rest. Yes, these rules I hope people would follow.

[Leledumbo]

Rule #3, is kinda questionable. Since pretty much anything is on the heap these days. Allocating and reallocating (whenever needed or not) in run-time. On the other hand, most of dynamic memory management is handled by the compiler, if developers are corresponding types: dynamic arrays, classes etc.. instead of using good-old pointers.

For a safety-critical code, this applies. Not for other cases, though. In my previous company, we use only statically allocated data. No dynamic allocation whatsoever. This is because our software must be verifiable in memory (both RAM and EEPROM) usage (we have very limited space), and dynamic allocation makes it nearly impossible. Memory allocation also means additional overhead of checking return value of memory allocation function or even the heavier exception handling of out of memory error. With static allocation, we eliminate the chance of code failing due to memory (de)allocation failure.

[jwdietrich]

Thanks for your suggestions. Unfortunately neither Castalia nor Peganza support Lazarus projects.

Fortunately, however, Lazarus and FPC provide some basic form of static code analysis, and it may be pretty much if the contents of Lazarus' messages window are exported. Nevertheless, I think that there is still some need for a more thorough tool.

[marcov]

Rule #7 (do not treat functions as procedures) is a bit odd. Since satisfying the rule, might cause violation in Rule #1 (complex/spaghetti code) and eventually Rule #4 (short function listing).

Moreover, probably no static analysis needed for this, just turn off extended syntax (($X-} ?)

[marcov]

Peganza seems to be maintained (last updates the second half of 2014)

Cool. Admitted last time I checked was in later D2006 times.

Castailia seems to be open source

That is only the parser, not the tool. Still I didn't know, pity that there is no testsuite (would have been fun for fcl-passrc)

[DelphiFreak]

Rule #1 "Don't use GOTO XYZ"

Today people often use "RAISE" which is even worse. ( RAISE means: GOTO SOMEWHERE and hope someone is catching/handling this situation)

 

[FPK]

Rule #7 (do not treat functions as procedures) is a bit odd. Since satisfying the rule, might cause violation in Rule #1 (complex/spaghetti code) and eventually Rule #4 (short function listing).

Moreover, probably no static analysis needed for this, just turn off extended syntax (($X-} ?)

Same with goto: Don't pass -Sg and FPC will not accept gotos.

[JuhaManninen]

Today people often use "RAISE" which is even worse. ( RAISE means: GOTO SOMEWHERE and hope someone is catching/handling this situation)

That is the whole idea of an exception. You raise it and hope it gets cought somewhere.
It is a brilliant way of handling errors. It carries information about the error automatically backwards in the call stack.
With a language that does not support exceptions, for example C, you must define variables for that purpose and pass them between function calls. Then a big portion of code and variables may deal with error handling which clutters the actual program logic.
Exceptions are a big improvement over that.

[skalogryz]

That is the whole idea of an exception. You raise it and hope it gets caught somewhere.

I believe the idea was somewhat perverted, since the exceptions are being used for any error handling. At least I presume this is what DelphiFreak is trying to say.

The question is are exceptions - exceptional?
The exceptional problem is running out of memory. In most cases the handler would attempt to save the existing data (without allocating more memory for operation) and terminate the program.

But if a file cannot be opened, is it an exception? or is it an possible and expected and behavior of the environment? and if it's the possible and expected, should the exception be risen? Exceptions raising/handling are quite expensive, compared to a classical function result processing.

[JuhaManninen]

But if a file cannot be opened, is it an exception? or is it an possible and expected and behavior of the environment? and if it's the possible and expected, should the exception be risen? Exceptions raising/handling are quite expensive, compared to a classical function result processing.

If a file cannot be opened, it is not expected but it is possible and then exceptions are a good way to handle it.
Exceptions can be used for any kind of errors. For example your method is passed a parameter which is not in the list of allowed values, then you raise an exception which is handled higher in the call stack.
As you know you can define different types of exceptions and handle only some of them in the try-except block. It is a very flexible system.
The exception object also carries an message, not only a type. I am quite amazed you want to go back to the clumsy C-style error handling.

How big is the speed penalty for using exceptions? I know there is a special frame in every function that deals with exceptions, but I thought it is not very expensive time-wise.