In my particular situation, I have a matrix class in C++ that overloads operator(), accepting a row and column index. Someone ages ago decided that indices are 1-based, not 0-based. If this class receives an out-of-bounds index, it returns 0 instead of throwing an exception. Unfortunately, as I discovered today, there’s old code that obviously hasn’t been used lately and which mistakenly uses 0-based indexing with this class instead of 1-based indexing. I’d like to create a rule that checks for out-of-bounds arguments, even if those cases don’t result in out-of-bounds memory access. If I could write a custom C++ rule, I would try that, but it appears that isn’t supported and isn’t on the roadmap. I don’t want to change the method to throw an exception in case that breaks something else obscure. Another place where this error can occur is having one loop iterate over both a matrix and equivalently sized array. The difference in starting index will cause some confusion and thus problems.
Turning this into a general feature that others may find useful, would it be possible to have a kind of rule template. Five things would be needed - the class name, method name, argument name, minimum value and maximum value. I think the logic applied to checking for out-of-bounds access could be applied here to check if the argument can ever be outside of those bounds. Typically, the index will come from a loop variable and the start value of that loop will probably be hard-coded to 0.
This is Windows code using ATL and MFC, so open source tools fail to process it. I don’t know of an external tool where I could do this kind of check.
Why should this be a priority now? It matters to me because this matrix class is used in dozens of projects covering thousands of lines of C++ just using that method. In general though, I don’t know how useful this will be for others though. I can only picture it being used with custom storage classes, and one obvious counter argument there is that out-of-bounds access should generate an exception. Sadly this particular class’s interface was set ages ago (10-20 years ago) so I am loath to change it now. It might have some usefulness for math functions that are only defined within a certain range, like log, ln, sqrt.
Welcome to our community.
I understand your situation, and it feels like there is a generic need.
Though we are not aiming to develop very configurable rules as they are rarely used, neither we want to develop some custom ways to inject information into the code.
Though, I acknowledge the need and the interest. We keep it on our radar, and we might develop ways to help with that in the future. For example, if C++ was ever to include contracts, this could be a way in.
Yes, contracts looks like a promising idea. Another idea that came to mind is to check assert statements or add some kind of assertion comment that SonarQube would understand. I think that if assert was checked then I could add those assertions, run SonarQube checks on all code and thus arrive at (1) an updated API, and (2) confidence that existing code has been updated, thus not breaking anything.
I don’t know if SonarQube has any support for checking assert statements at compile time.
I think that would be a great improvement and motivate developers to start specifying the contracts in their code now and not in 5 years once it get’s standardized.
Thanks @jsinge for pointing out GSL. I’d be happy if SonarQube supported GSL’s Expects and Ensures macros, and later on the proper C++ standard when that becomes available. If that support did become available, I’d introduce GSL’s assertions immediately and use SonarQube to check for potential violations, fix them and be reasonably comfortable that I haven’t just broken the whole application .
There’s also the Boost.Contracts library: https://www.boost.org/doc/libs/1_80_0/libs/contract/doc/html/index.html). This looks much more powerful, perhaps some people will find it useful. If SonarQube does add support for contracts libraries, perhaps this could be the 2nd or 3rd one (if there’s enough demand). Personally, I think I’d be fine with GSL for the foreseeable future.
.