SFML community forums

General => General discussions => Topic started by: minirop on April 11, 2015, 12:37:36 am

Title: static analysis of SFML
Post by: minirop on April 11, 2015, 12:37:36 am
Hello,
as a test, I've tried PVS-Studio on SFML (master) and, considering I did it correctly, there is not many things to say (which is a good thing).

sfogl_StrToExtMap *entry = NULL;
entry = FindExtEntry(extensionName);
That's all folks!

Except the missing operator=(), the rest can be "forgotten" since it's mainly syntax choices¹ (but why the double assignment?)

++

¹: I know C-casts are discouraged, but with C structs and function, the static_cast should "win".
Title: Re: static analysis of SFML
Post by: SuperV1234 on April 11, 2015, 10:15:28 pm
Could you post the complete log?
Title: Re: static analysis of SFML
Post by: minirop on April 12, 2015, 12:34:42 am
here it is (http://files.peyj.com/SFML-log.plog). it's only an XML file (1.11MB).
Title: Re: static analysis of SFML
Post by: Jabberwocky on April 12, 2015, 09:24:19 pm
As you noted, it looks to me like SFML passed this test remarkably well!  Thanks for the post, minirop.
Title: Re: static analysis of SFML
Post by: binary1248 on April 13, 2015, 08:04:03 am
The reason why there are so many warnings in GLLoader.cpp is because, as some might already know, it is an automatically generated loader... in C. I already went ahead and modified it a lot mostly getting rid of things we don't use anyway, but didn't really dig into the finer details of the code that remained. I guess now that I realize that there might be reason to look into it more, I might go ahead and fix up most of those warnings.
Title: Re: static analysis of SFML
Post by: Hiura on April 13, 2015, 09:31:34 am
Nice report.  :)

I'll create a PR for the SoundSource bit.

Regarding FT_RENDER_MODE_NORMAL in Font.cpp, it's better to keep it that way.

As for null string testing, I'd rather keep it that way since it's more idiomatic. But does someone disagree?

Title: Re: static analysis of SFML
Post by: Nexus on April 13, 2015, 11:47:01 am
  • "The '(FT_RENDER_MODE_NORMAL)' named constant with the value of 0 is used in the bitwise operation. font.cpp:485"
How does that line look? Because in line 485 (master) (https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/Font.cpp#L485), there are different constants:
if (FT_Load_Char(face, codePoint, FT_LOAD_TARGET_NORMAL | FT_LOAD_FORCE_AUTOHINT) != 0)

(but why the double assignment?)
The separate declaration and initialization is of course pointless, it can be fixed too.
Do you have all the occurrences in text format?

I guess now that I realize that there might be reason to look into it more, I might go ahead and fix up most of those warnings.
Don't we have to do everything again if we change something and regenerate GLLoader.cpp? If it doesn't take long, fine, but let's not waste our time on fixing generated files just for cosmetic reasons :P

As for null string testing, I'd rather keep it that way since it's more idiomatic. But does someone disagree?
Is it really more idiomatic? After all, the empty() method exists for only this purpose ;)
Title: Re: static analysis of SFML
Post by: binary1248 on April 13, 2015, 12:16:12 pm
Don't we have to do everything again if we change something and regenerate GLLoader.cpp? If it doesn't take long, fine, but let's not waste our time on fixing generated files just for cosmetic reasons :P
Well, basically any time anybody adds (or maybe even removes?) extensions, what they would have to do is generate the verbatim GLLoader files and extract the bits and pieces that are to be added to SFML's modified version.

This might seem like a lot of work at first glance, but trust me, it really isn't. If more than 100 lines get changed in those files for what I consider a "small extension", then something probably went wrong. :P Typically the number of lines that get changed is anywhere from 10 to 40 for "average sized extensions".

You can take a look at the GL 1.1 diff (https://github.com/SFML/SFML/pull/858/files). When adding an extension, changes only have to be made in 7 different places within the files. I can do this in a matter of minutes, no idea how long someone else would take. :P
Title: Re: static analysis of SFML
Post by: minirop on April 13, 2015, 12:46:24 pm
(but why the double assignment?)
The separate declaration and initialization is of course pointless, it can be fixed too.
Do you have all the occurrences in text format?
all in glloader.cpp, L385/386, L463/464 and L496/502.
looking at the last one make me think it's probably for pre-C99 compatibility (declare all variable then assign them)
Title: Re: static analysis of SFML
Post by: Hiura on April 13, 2015, 12:50:47 pm
As for null string testing, I'd rather keep it that way since it's more idiomatic. But does someone disagree?
Is it really more idiomatic? After all, the empty() method exists for only this purpose ;)

Well, it's a question of taste, or how you see `std::string`, in the end, true. But I think the `empty` function is here because you can see it as a container. Personally, I see it as a string so checking for emptiness is not that conventional to me.
Title: Re: static analysis of SFML
Post by: minirop on April 14, 2015, 03:18:22 pm
I tried cppcheck to compare. There are a few "unused variable" like MainAndroid.cpp:L125, lJavaVM is never used, and a few "the score of the variable 'XXX' can be reduced".
Only one warning stands out from the rest, Window\Unix\GlxContext.cpp:L56,57, the initializer list is in the wrong order.