I have begun to run Smatch on the U-Boot source code. This is showing up a number of different classes of issue.

1) Inconsistent indentation.
While I would like to fix all of these reports, they are not actually causing any bugs. So I am going to assume that in the interest of keeping churn in the source down to a minimum that these can be ignored.

2) Warnings about large usage of the stack.
I am going to ignore these, at least for the moment. It would be good practice not to do this though.

3) Uninitialised variables.
These generally result from possible but unlikely code paths. These should be checked though.

4) Possible buffer overflows.
Most of these are probably not possible in practice but Smatch has not been able to absolutely confirm that. Some however are going to be real bugs. These need to be checked.

5) Ignoring unreachable code.
Mostly this is deliberate (if unnecessary). Sometimes it is the result of config choices. Also used as a way to disable some broken test code.

6) Variable dereferenced before check.
There are instances where a variable is dereferenced early in the function and then later there is a null check for that variable.

7) Always true or always false tests.
eg checking if an unsigned variable is negative.

8) Probable incorrect tests.
eg use of && instead of &, etc

9) Other things.

I am going to follow this email with a sample email that can be produced for one report that I believe shows an actual bug.

I do not wish to swamp the mailing list but I do also believe that we should be aware of these issues and absolutely must resolve them where needed.

The code coverage from a run of Smatch depends on the platform chosen as the target of the build and I am never going to run all of them. But maybe it will be possible to run at least one build in CI with Smatch enabled to catch newly introduced issues, at least in those areas of code that are used in that build. It would be good for all developers to run Smatch on their platform builds to broaden the code coverage as far as possible.

Andrew

Reply via email to