Compiling on debian (gcc 12.2.0) and windows/msys2 (gcc 14.1.0) emits warnings about uninitialized variables in Json::Value::swapPayload():
In function 'std::_Require<std::__not_<std::__is_tuple_like<_Tp> >, std::is_move_constructible<_Tp>, std::is_move_assignable<_Tp> > std::swap(_Tp&, _Tp&) [with _Tp = Json::Value::ValueHolder]',
inlined from 'void Json::Value::swapPayload(Json::Value&)' at ../ext/json/jsoncpp.cpp:2874:12,
inlined from 'bool Json::Reader::readValue()' at ../ext/json/jsoncpp.cpp:436:31:
D:/a/_temp/msys64/mingw64/include/c++/14.1.0/bits/move.h:222:7: warning: 'v.Json::Value::value_' may be used uninitialized [-Wmaybe-uninitialized]
222 | __a = _GLIBCXX_MOVE(__b);
| ^~~
Coverity Scan flags the same as a high-impact defect.
Are these false positives?
If not, can we patch them?
Or can we delete the whole Json::Reader from the amalgamated source, since we're never reading JSON anyway? (I tried this but suddenly some string-type JSON elements started disappearing at runtime.)
Would a more sensible solution be to move to nlohmann's json for the 1.0 release?
Plus: It's well-tested and actively developed.
Plus: It's packaged in apt and homebrew.
Plus: It supports custom element order out-of-the-box; no need to patch (like currently in redsea).
Minus: It would add an external dependency. But it's not like there's a goal to try and avoid those.
Compiling on debian (gcc 12.2.0) and windows/msys2 (gcc 14.1.0) emits warnings about uninitialized variables in Json::Value::swapPayload():
Coverity Scan flags the same as a high-impact defect.