nutwriter.hpp / -Wmaybe-uninitialized warning

[desertwitch]

  CXX      libnutconf_la-nutwriter.lo
In file included from ../include/nutwriter.hpp:29,
                 from nutwriter.cpp:25:
In member function 'bool nut::Settable<Type>::operator==(const Type&) const [with Type = bool]',
    inlined from 'nut::BoolInt::operator int()' at ../include/nutconf.hpp:424:11,
    inlined from 'std::string nut::serializeCertHost(const CertHost&)' at nutwriter.cpp:193:6:
../include/nutconf.hpp:100:32: warning: '*(unsigned char*)((char*)&bi + offsetof(nut::BoolInt, nut::BoolInt::b.nut::Settable<bool>::_value))' may be used uninitialized [-Wmaybe-uninitialized]
  100 |                         return _value == val;
      |                                ^~~~~~
nutwriter.cpp: In function 'std::string nut::serializeCertHost(const CertHost&)':
nutwriter.cpp:184:22: note: '*(unsigned char*)((char*)&bi + offsetof(nut::BoolInt, nut::BoolInt::b.nut::Settable<bool>::_value))' was declared here
  184 |         nut::BoolInt bi;
      |                      ^~
At global scope:
cc1plus: note: unrecognized command-line option '-Wno-unknown-warning-option' may have been intended to silence earlier diagnostics
cc1plus: note: unrecognized command-line option '-Wno-reserved-identifier' may have been intended to silence earlier diagnostics

Hello! I caught this one today building the current master on Slackware 15.1 with gcc 13.2.0

[jimklimov]

Probably fallout of #2425 / #2294 although the last few commits were about squashing this sort of issue with bogus usages of the Settable<T> entries specifically to avoid such warning. Maybe missed one, but CI builders no longer complained :\

"Bogus" IMHO in the sense that this class and its usages (unless something was missed) separately tracks if the payload was set() and only returns its value (or callers ask for it) if it was - allowing to not write into configs the values not initialized in current class instances that represent the config in C++ class (its properties).

That said, the issues I was addressing - as well as this one - happened to BoolInt which I've introduced in that PR on top of predecessors' code, so maybe I did botch something in the grand design :)

[jimklimov]

UPDATE: The warning above pointed to another use-case similar to the one I plugged in the original PR. No idea why my copy of gcc (and all those on NUT CI) at most complained there and not here for essentially same pattern.