Post==2896379==

==2896379== logger no timeout configured, using default 1000 ms ==2896379== ==2896379== HEAP SUMMARY: ==2896379== in use at exit: 0 bytes in 0 blocks ==2896379== total heap usage: 2 allocs, 2 frees, 74,752 bytes allocated ==2896379== ==2896379== All heap blocks were freed -- no leaks are possible ==2896379== ==2896379== For lists of detected and suppressed errors, rerun with: -s ==2896379== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) You can see Valgrind is complaining about an uninitialized variable created on the stack: Uninitialised value was created by a stack allocation The reason is that GCC handles the two cases with two different warnings. In the first example, value is uninitialized on every path, and -Wuninitialized reports it even at `default` \-O0. In the second example, timeout\_ms is assigned only inside the if block in read\_timeout\_ms(), so it is uninitialized on only one path. That case belongs to -Wmaybe-uninitialized, which relies on the data-flow analysis done by the optimizer, so it does not run at -O0. If you build the same file at -O2, GCC does catch it: ~/cpp_26_uninitialised$ g++ -std=c++23 -O2 -Wall -Werror config_timeout_warning_test.cpp -o timeout_warning_test config_timeout_warning_test.cpp: In function ‘int read_timeout_ms(std::string_view)’: config_timeout_warning_test.cpp:24:12: error: ‘timeout_ms’ may be used uninitialized [-Werror=maybe-uninitialized] 24 | return timeout_ms; | ^~~~~~~~~~ config_timeout_warning_test.cpp:11:9: note: ‘timeout_ms’ was declared here 11 | int timeout_ms; | ^~~~~~~~~~ cc1plus: all warnings being treated as errors This is still not a guarantee. The result of -Wmaybe-uninitialized depends on the optimization level and on how much the optimizer can see, so it can change between GCC versions and between builds. Debug builds are usually at -O0, which is exactly where the warning is missing. If there is anything that I have missed, please comment; I'm happy to be corrected. https://redd.it/1wyvcvg @r_cpp