Checks using 'splint'

[mdeweerd]

#2639 adds splint as a workflow.

• do_splint.sh (with splint installed) with arguments will check only those files without disabling warnings.
  Without arguments it checks "all" files (a lot of files were excluded).
• Except for a duplicate function warning, I disabled all messages and files that could not be parsed.
• Files are excluded by grepping the list of 'c' files resulting from a find (in do_splint.sh). So to enable parsing for a file in the workflow, that has to be updated.

Most of the time parsing fails because variables are not defined at the start of a block.
I adjusted some files for that and in 'include/abuf.h' I added a '#ifndef S_SPLINT_S' to work around the elipsis limitation of splint.

[zuckschwerdt]

Very interesting checks, thanks. Some quick notes:

There is still older code with irregular style. We'll maybe normalize that someday, but for now keep it because the authors intended to convey meaning with the style.

We switched to relaxed c99 variable definitions to make reasoning and refactoring easier. We don't want to change that. And esp. widening the scope in e.g. loops is not acceptable, a local loop var will scope to the inner block and should not be visible outside (e.g. after the loop is done).

The "function redefined" (e.g. nexus.c) warning is odd. I assume it's about the declaration of rubicson_crc_check() in multiple files? I see no difference between declaration in a header or inline in source?

[mdeweerd]

Defining the function using "extern" keeps splint happy.

Relaxed C99 variable definition support is a long pending "issue" as there is no real codeowner for splint.

splintchecker/splint#12

[zuckschwerdt]

For non-inline functions, extern is not needed as it is on by default (per C99 standard). So the check is wrong here. But I don't see harm in making an otherwise useful checker happy by adding the storage-class modifier though ;)

[mdeweerd]

I've update the script - 55 C files can be parsed and hence be checked for recommendations.

[gdt]

What's the scope/intent of this issue? What's the path to closing it? It feels like a discussion of things noticed from the PR. We've resolved, I think, that splint expects stricter c99 than rtl_433's style guide, but I'm not sure what else.

[mdeweerd]

Given that splint does not support C99 and that RTL433 is in favor of using this feature, there is no real reason to push for it.

I was under the impression that RTL_433 treis to keep (somewhat) compatible with older cversions.

One of the main things that I learn from this splint analysis is that typing can be improved - IMHO the use of uint16_t and similar should be more widely applied. Also, currently int16_t may be assigned to ints and vice-versa without any casts - while cast are not required by the language, they indicate the developer's intention, which allows detecting unwanted conversions.

There are some other lessons as well, but the above are the main ones.

This is the log for the parsable files with "no" exclusions: analysis.log

[gdt]

Certainly if you want to file PRs or issues for specific cleanups that seems reasonable; I can't of course tell you how they will go over though.

As far as this issue goes, it seems it has run it course, we learned some things, and it's time to close it. If you agree, please do.