==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