I recently found a non-deterministic behavior in my application that was due to a missing field initialization.
Here is a snippet of the actual problem:
struct foo {
foo() {}; // <— bar is not initialized here.
int getBar() const {
return bar; // <— this returns an uninitialized value.
}
private:
int bar;
};
I’ve compiled the attached cpp file that contains this snippet with -Wall -Wextra -Wuninitialized, but no warning is issued (trunk 203678).
Is there an option to make clang warn about that?
Clang does not have a warning for uninitialized fields in class methods. I’ve looked before to add a warning to flag any unused fields at the end of the a constructor. However, there were good reasons to have uninitialized fields, such as having an Init() method later that initializes the fields, or a guard variable to protect against uninitialized use. Also, -Wuninitialized typically warns on the use of an uninitialized variable, not the mere presence of one.
The other idea is to do cross method analysis, either using the control flow of a program to determine which methods are used in which order, or testing methods against constructors. Such an analysis would likely be too expensive, and would be more suited for static analysis.
So there’s no warning for this yet, and probably won’t be unless we find a better way to detect it.
Clang does not have a warning for uninitialized fields in class methods.
I've looked before to add a warning to flag any unused fields at the end of
the a constructor. However, there were good reasons to have uninitialized
fields, such as having an Init() method later that initializes the fields,
or a guard variable to protect against uninitialized use. Also,
-Wuninitialized typically warns on the use of an uninitialized variable, not
the mere presence of one.
The other idea is to do cross method analysis, either using the control flow
of a program to determine which methods are used in which order, or testing
methods against constructors. Such an analysis would likely be too
expensive, and would be more suited for static analysis.
We already have at least one cross-method analysis which could
actually be used as the basis for the warning under discussion here:
-Wunused-member-variable. This warning only fires if there are no
friends and a private member in a situation where all member functions
are defined in one translation unit. So we could use this to show
that there's no initialization of the variable anywhere, but there are
uses of it. (essentially the same as -Wunused-member-variable, except
allow reads as well)
The analyzer also catches the particular case in your stripped-down test file, and should do so on real code as long as it’s all visible in one translation unit. It’d be a lot harder to make this a cross-TU analysis, of course.
Clang does not have a warning for uninitialized fields in class methods.
I’ve looked before to add a warning to flag any unused fields at the end of
the a constructor. However, there were good reasons to have uninitialized
fields, such as having an Init() method later that initializes the fields,
or a guard variable to protect against uninitialized use. Also,
-Wuninitialized typically warns on the use of an uninitialized variable, not
the mere presence of one.
The other idea is to do cross method analysis, either using the control flow
of a program to determine which methods are used in which order, or testing
methods against constructors. Such an analysis would likely be too
expensive, and would be more suited for static analysis.
We already have at least one cross-method analysis which could
actually be used as the basis for the warning under discussion here:
-Wunused-member-variable. This warning only fires if there are no
friends and a private member in a situation where all member functions
are defined in one translation unit. So we could use this to show
that there’s no initialization of the variable anywhere, but there are
uses of it. (essentially the same as -Wunused-member-variable, except
allow reads as well)
The analyzer also catches the particular case in your stripped-down test file, and should do so on real code as long as it’s all visible in one translation unit. It’d be a lot harder to make this a cross-TU analysis, of course.
The actual problem is cross-TU.
Is there a plan or a way to run the analyzer on several TU?
It’s a big problem that’s not likely to happen any time soon. Clang is just too much designed to work on one TU at a time, so we’d need a whole lot of new infrastructure to handle this. It is something we want to do some day.
Clang does not have a warning for uninitialized fields in class methods.
I’ve looked before to add a warning to flag any unused fields at the end of
the a constructor. However, there were good reasons to have uninitialized
fields, such as having an Init() method later that initializes the fields,
or a guard variable to protect against uninitialized use. Also,
-Wuninitialized typically warns on the use of an uninitialized variable, not
the mere presence of one.
The other idea is to do cross method analysis, either using the control flow
of a program to determine which methods are used in which order, or testing
methods against constructors. Such an analysis would likely be too
expensive, and would be more suited for static analysis.
We already have at least one cross-method analysis which could
actually be used as the basis for the warning under discussion here:
-Wunused-member-variable. This warning only fires if there are no
friends and a private member in a situation where all member functions
are defined in one translation unit. So we could use this to show
that there’s no initialization of the variable anywhere, but there are
uses of it. (essentially the same as -Wunused-member-variable, except
allow reads as well)
The analyzer also catches the particular case in your stripped-down test file, and should do so on real code as long as it’s all visible in one translation unit. It’d be a lot harder to make this a cross-TU analysis, of course.
The actual problem is cross-TU.
Is there a plan or a way to run the analyzer on several TU?
It’s a big problem that’s not likely to happen any time soon. Clang is just too much designed to work on one TU at a time, so we’d need a whole lot of new infrastructure to handle this. It is something we want to do some day.
I understand.
Is there a PR or a radar I can follow?
