The map_block->designation.{dig,smooth} are reset to zeros when a job
posting is created for the designation. The job is then used to override
the designation state in the map_block. To make the new designation set
propogate to jobs the job structure would require updating. The update
would be possible a complex operation. The simple alternative is to
remove the job and let df create a new job in the next tick.
Fixes#1229
This makes jsoncpp a submodule that can be build directly from git
sources. This changes depends/jsoncpp to depends/jsoncpp-sub to avoid
filename conflict if someone tries to use git bisect.
jsoncpp library name changes to jsoncpp_lib_static.
jsoncpp version is the latest tagged release.
Passing a 64bit integer to Json::Value fails to find matching. Even
tough long long int is also 64bits gcc considres long long int different
to long int. But fix can't be as simple as removing an long from type
because that would reduce 32bit builds to have only 32bit maximum int
size. But standard offers fixed width integer types that can be used to
get correct underlying type depending on platform.
gcc supports type checks for printf parameters which can catch some hard
to reproduce bugs. Possible bugs happen when the parameter value is
intepreted differently to the variable value.
Example warnings follow
../library/LuaWrapper.cpp:1011:86: warning: format ‘%llu’ expects argument
of type ‘long long unsigned int’, but argument 3 has type ‘uint64_t
{aka long unsigned int}’ [-Wformat=]
../plugins/follow.cpp:159:35: warning: format not a string literal and no
format arguments [-Wformat-security]
All platforms seems to either have compiler supporting c++14. Windows
already requires msvc2015 that supports c++14 which should make it
minimal issue to require c++14 support from all compilers because gcc
is pretty easy to upgrade.
vsnprintf man page claims:
"If an output error is encountered, a negative value is returned."
That means we has to call vsnprintf twice at most to have whole output
written to a string. But in case of error we return an empty string.
The code also optimizes an expected common case of outputting single
line with a small stack allocated buffer. If the stack buffer is too
small then it uses std::string::resize to allocate exactly enough memory
and writes directly to std::string.
Second call could use vsprintf because memory is known to be large
enough. But I think that difference isn't detectable outside micro
benchmarks.
Lethosor
Pauli
JapaMala
lethosor
PatrikLundell