Sonarcloud does not catch unguarded access to an array

SonarCloud
1
  • ALM used : GitHub
  • CI system used: Github Actions
  • Scanner command used when applicable (private details masked):
    sonar-scanner --define sonar.projectKey=balaji-nordic_unit-test-experiments
    –define sonar.organization=balaji-nordic
    –define sonar.host.url=“${{ env.SONAR_SERVER_URL }}”
    –define sonar.exclusions=“CMakeFiles”
    –define sonar.cpd.exclusions=“CMakeFiles”
    –define sonar.cfamily.build-wrapper-output=“${{ env.BUILD_WRAPPER_OUT_DIR }}”
    –define sonar.cfamily.gcov.reportsPath=“gcov_reports_dir”
  • Languages of the repository: C
  • Only if the SonarCloud project is public, the URL : https://sonarcloud.io/project/overview?id=balaji-nordic_unit-test-experiments
  • Error observed (wrap logs/code around with triple quotes ``` for proper formatting)
    I expect sonarcloud to warn about unguarded access to the memory that may result in possible memory overwrite. But it does not seem to do that unless I write a test case that actually makes the memory violation happen.
  • Steps to reproduce:
#define SIZE_OF_ARRAY 2
int array[SIZE_OF_ARRAY];

int insert_in_array(int pos)
{
	array[pos] = 1;
	return 0;
}

A call to insert_in_array(1) does not result in any bug reports. But insert_in_array(4) does result in the expected bug report. I expect sonarcloud to atleast warn about the unguarded memory access irrespective whether the function is called with arguments that lead to the manifestation of the bug as the function insert_in_array() is a public function.

3

Indeed, the function could be called with parameters that would invoke undefined behavior.
However, it could be used safely as well, by passing 0 or 1 to the function.
It’s really common to have similar implicit contracts in the form of documentation around such functions.

One could not rule out the possibility, that this function is only used in a safe manner, so we should not report a definite bug there.

I can also see your point that in some situations we wish that we could catch such cases, however, in practice raising an issue for such cases would greatly degrade the user-experience at scale. So, we only raise an issue if we see an invocation to this function with an argument that would be known to raise undefined behavior.

This suggestion is fairly similar to CPP-4078, but for array accesses.
I created the CPP-4113 ticket to record traction if there is demand for a stricter version of the rule S3519.

Let me know if you have further questions.

1 Like
4

Thanks for your reply. I agree to your views. It is always a challenge decide which can and can not be noisy to developers. It may be an idea to classify this kind of issues as ‘code smell’ instead of a bug.

6

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.