[question] Differences between doctest and googletest (gtest) for uninitialised local variables in test cases

[stephenlevitt]

This is not a bug report, per se. I'm just trying to understand why doctest produces a different output to gtest (and what I was expecting).

I have a simple Date class with no constructor. I would expect the initialisation of its integer data members (day and year) to be undefined as described here: https://stackoverflow.com/questions/2417065/does-the-default-constructor-initialize-built-in-types

The test case in doctest is:

TEST_CASE("Date has uninitialised state") {
   Date today;	
   std::cout << "Today is: " << endl;
   printDate(today);
}

The test case in gtest is:

TEST(Date, hasUninitialisedState) {
    Date today;	
    std::cout << "Today is: " << endl;
    printDate(today);
}

printDate is:

void printDate(const Date& date) {
	cout << date.day() << "/"
		// cast to an integer to allow the month to be sent to the stream
        << static_cast<int>(date.month()) << "/"
		<< date.year()
		<< endl;
}

doctest's output is:

doctest] doctest version is "1.2.1"
[doctest] run with "--help" for options
Today is:
0/0/0

gtest's output is:

Running main() from gtest_main.cc
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from Date
[ RUN      ] Date.hasUninitialisedState
Today is:
5382784/0/16

Why are the Date's integer values default initialised to 0 when using doctest?

[onqtam]

It should be purely by coincidence. Perhaps just before calling the test function some other internal function of doctest has used the same stack space for a variable which left the memory with zeroes.

The following program shows this:

#include <cstdio>

void f() {
    int a = 45;
    printf("f(): %d\n", a);
}

void g() {
    int b; // uninitialized - but will occupy the same stack space as "a" from "f()"
    printf("g(): %d\n", b);
}

int main() {
    f();
    g();
}

Built without optimizations (G++ 7 under Windows) it prints the following:

f(): 45
g(): 45

Reads from uninitialized variables is dangerous :) - static analysis / compiler warnings or some runtime tooling (sanitization or valgrind) may help in detecting such cases.

[stephenlevitt]

Thanks for the clarification and your speedy response!

Doing this prior to the allocation of the Date:

    auto i = {1.0,1.3,1.4,1.5,1.6,1.7,1.8,1.9,10.2,11.0,1.2,1.3,1.23};
    auto i2 = 1.0;

illustrates that the memory is uninitialised and that the zeros are purely co-incidental.

Reads from uninitialized variables is dangerous :)

Absolutely! This is for a student exercise to illustrate that the data members are, in fact, uninitialised so chance was not working in my favour :-)

[onqtam]

Closing this :)