And a thorough description of the problem / question:
Hello!
Recently, I found that the rule C: s836 cannot be detected correctly in the production environment. Some structural variables are called before being initialized, but they are not detected. I want to verify whether sonarlint can detect this situation, but the result is also disappointing. Here is my code and compile_ cammad.json。 Is it my configuration error?
#include <stdint.h>
#include <stdio.h>
struct STUDENT
{
int age;
};
void print_student(STUDENT student){
int oldAge=student.age;
student.age=oldAge*2;
}
int main() {
printf("const char *const Format, ...");
STUDENT student;
print_student(student);
int64_t age;
student.age=age;
}
Unfortunately, I was not able to reproduce the issue. The difference may be caused by multiple different reason, so could you please share full analysis logs, using the steps described on this page.
#include <stdint.h>
#include <stdio.h>
#include <stdbool.h>
typedef struct
{
int age;
char name[20];
} student_t;
void print_student(student_t student){
int oldAge=student.age;
student.age=oldAge*2;
printf("student's name is %s \n",student.name);
}
student_t copy_student(student_t student,bool iscopy){
student_t r;
if (iscopy) {
r=student;
}
return r;
}
int copy_int(bool flag, int b) {
int a;
if (flag) {
a = b;
}
return a; // Noncompliant - "a" has not been initialized in all paths
}
int main() {
printf("%f\n", 1.2);
student_t student;
print_student(student);
student_t student2={12,"zhangjiuwang"};
student=copy_student(student2,false);
print_student(student);
student=copy_student(student2,true);
print_student(student);
}
Firstly, in the original post, you have included a bit different example, and from the context, it looked like no issues are raised in it. Is that thing now resolved, and no additional help is needed there?
For your second example, I have checked your code, and this is the same issue as reported in this JIRA ticket., and I have added your example to it. Thank you for the report.
The ExiitCode != 0 is a generic error that is produced in case of a crash (failure) of the analysis of the source file. Log of such effect may be caused by multiple reasons. Given that, you are most likely experiencing other problems that produce the same log output. In such a case sharing reproducer and analysis logs will help us to address it.
We do not plan to work on this specific issue in the near future. However, we are putting a lot of effort into improving our bug detection engine, and the issue may get addressed as a by-product of these changes.
