I have the following piece of code:
class circularList
{
public:
circularList() : data(0), next(this) {}
public:
int data;
circularList* next;
};
int main()
{
circularList* root = new circularList;
}
I keep getting a warning saying that variable circularList* next
is uninitialized, but I can see if I run the code that is initialized with the address of the pointer root
.
In computing, an uninitialized variable is a variable that is declared but is not set to a definite known value before it is used. It will have some value, but not a predictable one. As such, it is a programming error and a common source of bugs in software.
An uninitialized variable has an undefined value, often corresponding to the data that was already in the particular memory location that the variable is using. This can lead to errors that are very hard to detect since the variable's value is effectively random, different values cause different errors or none at all.
Description. The code uses a variable that has not been initialized, leading to unpredictable or unintended results. Extended Description. In some languages such as C and C++, stack variables are not initialized by default.
Use of uninitialized memory means reading data from the buffer that was allocated but not filled with initial values. The program behavior in this case is considered an error which is quite difficult to detect sometimes.
The pointer is clearly initialised in the example. This appears to be a compiler bug, as there should be no warning. You should report it to the maintainers.
It's either bug or misfeature of static analyzer. It's intended behaviour is to react on code like this:
class circularList
{
public:
circularList() : data2(0), data1(this->data2) {}
public:
int data1;
int data2;
};
data2
actually initialized after data1
(which produces another warning) and expression starting with this
, this->XXX
, prompts the check. In your case ->XXX
is not present and it confuses the analyzer. This should be a regression, because some builds of older compilers (as old as VS2005 or VS2008), or some very ancient gcc
or lcc
(not stable builds) expressed similar concerns.
There is still a case when this
should not be used - if there is a virtual inheritance, or if initialization tries to call a virtual function.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With