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.
YCM flag function returning None result an error from YCM python code
everytime a file is opened. The None return can happen if database
lookup fails for any reason. To let YCM have resonable flags without
database entry the .ycm_extra_conf.py can include default fallback
flags.