Recent

Author Topic: Static code analysis  (Read 16394 times)

jwdietrich

  • Hero Member
  • *****
  • Posts: 1169
    • formatio reticularis
Static code analysis
« on: January 10, 2015, 01:38:07 pm »
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.
function GetRandomNumber: integer; // xkcd.com
begin
  GetRandomNumber := 4; // chosen by fair dice roll. Guaranteed to be random.
end;

http://www.formatio-reticularis.de

Lazarus 2.0.10 | FPC 3.2.0 | PPC, Intel, ARM | macOS, Windows, Linux

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 9081
  • FPC developer.
Re: Static code analysis
« Reply #1 on: January 10, 2015, 02:40:38 pm »
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

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2558
    • havefunsoft.com
Re: Static code analysis
« Reply #2 on: January 10, 2015, 03:25:40 pm »
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 :)
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2558
    • havefunsoft.com
Re: Static code analysis
« Reply #3 on: January 10, 2015, 03:26:44 pm »
a crystal ball suggests that FPC syntax is not supported. fpc-passsrc is recommended for the update and usage :)
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

jwdietrich

  • Hero Member
  • *****
  • Posts: 1169
    • formatio reticularis
Re: Static code analysis
« Reply #4 on: January 10, 2015, 04:07:18 pm »
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.
function GetRandomNumber: integer; // xkcd.com
begin
  GetRandomNumber := 4; // chosen by fair dice roll. Guaranteed to be random.
end;

http://www.formatio-reticularis.de

Lazarus 2.0.10 | FPC 3.2.0 | PPC, Intel, ARM | macOS, Windows, Linux

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2558
    • havefunsoft.com
Re: Static code analysis
« Reply #5 on: January 10, 2015, 04:29:28 pm »
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.
« Last Edit: January 10, 2015, 04:40:12 pm by skalogryz »
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

Leledumbo

  • Hero Member
  • *****
  • Posts: 8304
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Static code analysis
« Reply #6 on: January 10, 2015, 05:48:01 pm »
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

  • Hero Member
  • *****
  • Posts: 1169
    • formatio reticularis
Re: Static code analysis
« Reply #7 on: January 24, 2015, 12:20:32 pm »
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.
function GetRandomNumber: integer; // xkcd.com
begin
  GetRandomNumber := 4; // chosen by fair dice roll. Guaranteed to be random.
end;

http://www.formatio-reticularis.de

Lazarus 2.0.10 | FPC 3.2.0 | PPC, Intel, ARM | macOS, Windows, Linux

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 9081
  • FPC developer.
Re: Static code analysis
« Reply #8 on: January 24, 2015, 04:41:38 pm »
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

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 9081
  • FPC developer.
Re: Static code analysis
« Reply #9 on: January 24, 2015, 04:42:59 pm »
Peganza seems to be maintained (last updates the second half of 2014)

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

Quote
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

  • Sr. Member
  • ****
  • Posts: 251
    • Fresh sound.
Re: Static code analysis
« Reply #10 on: January 24, 2015, 06:29:12 pm »
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)

 >:D
« Last Edit: January 24, 2015, 06:31:28 pm by DelphiFreak »
Linux Mint 19.1, Lazarus 2.0, Windows 7&10, Delphi 7, Delphi 10.3 Rio

FPK

  • Moderator
  • Jr. Member
  • *****
  • Posts: 90
Re: Static code analysis
« Reply #11 on: January 24, 2015, 07:29:58 pm »
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

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3965
  • I like bugs.
Re: Static code analysis
« Reply #12 on: January 24, 2015, 07:53:35 pm »
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.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

skalogryz

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 2558
    • havefunsoft.com
Re: Static code analysis
« Reply #13 on: January 24, 2015, 08:01:35 pm »
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.
« Last Edit: January 24, 2015, 08:37:00 pm by skalogryz »
Patron Cocoa Widgetset development https://www.patreon.com/skalogryz

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3965
  • I like bugs.
Re: Static code analysis
« Reply #14 on: January 24, 2015, 09:07:30 pm »
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.
Mostly Lazarus trunk and FPC 3.2 on Manjaro Linux 64-bit.

 

TinyPortal © 2005-2018