Some calculation show that with the current setup there will not be enough bytes
occupied for that, barring the case of malicious translation. Still should be
possible to have array overrun with specially crafted translation.
I failed to deduce why analyzer thinks E882 may not be triggered, though
conditions for triggering it are strange: it would trigger E882 only in the
single case “function returned non-number”. Cases “function thrown exception”,
or “built-in sorter encountered error” will neither yield E882 nor stop
sort()/uniq().
Note though that searching test code revealed that neither E702 nor E882 are not
tested anywhere.
It is hard to say whether it actually is uninitialized, need to go deeper into
regex code. Probably analyzer did not go that far as regmatch for sure would not
be initialized up until calling NFA/DFA engine functions, which is to be done by
pointer.
It appears that transchar() was working under assumption that
`transchar_nonprint()` may be used for multibyte characters while its
documentation stated exact opposite. It was not actually untrue though, except
that longer buffer would be needed then the one stated in documentation. But it
is false now with assert().
Should actually be silencing that for the sake of the case when `long` is
actually not 64-bit. But it appears that Vim had already defined maximal line
number. And even declared that exact value invalid, so no need in silencing.
closes#8196
For historical reasons, uint64_t and friends are defined both as
typedefs and macros. Some platforms that do that define the macros as
identity (#define uint64_t uint64_t), others like NetBSD define to the
backing type (#define uint64_t __uint64_t). This is normally
transparent, except when multiple levels of macro expansions are used
inconsistently.
MSBuild still returns a non-zero exit code because it detects the word "error" in the stdout which is caused by some of the test names such as api/buf {get,set,del}_line get_line : out-of-bounds is an error.
CMake mailing list thread:
https://cmake.org/pipermail/cmake-developers/2015-October/026775.html
There isn't any good solution for it, so I modified the build script to detect the error message printed by RunTests.cmake.
