| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
| |
assert() is compiled out for release builds, but we don't want to
continue running in these impossible situations.
This also resolves the "implicit fallthrough" warnings for the asserts
in switch cases.
|
|
|
|
|
|
|
|
|
|
|
| |
UBSAN with clang 10.0 is checking for adding offsets to a `NULL` pointer
which is not allowed. This is not yet checked in the version of clang
used in CI (7.0.0). I will work on cases of this so that tests passes
locally for me.
This could be tested in CI by either upgrading the clang of the
ASAN/UBSAN to 10.0, or add yet another CI target which builds with
clang 10.0.
|
|
|
|
|
|
| |
Problem: VAR_SPECIAL is also used for booleans.
Solution: Add VAR_BOOL for better type checking.
https://github.com/vim/vim/commit/9b4a15d5dba354d2e1e02871470bad103f34769a
|
|
|
|
|
|
|
| |
ref #343
Though I don't see a strong benefit, it isn't too much of a burden, and
maybe avoids confusion in some cases.
|
| |
|
|\
| |
| | |
Add a way to collect list usage statistics
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** CID 169163: Null pointer dereferences (FORWARD_NULL)
/src/nvim/eval/decode.c: 290 in decode_string()
284 if (elw_ret == -1) {
285 tv_clear(&tv);
286 return (typval_T) { .v_type = VAR_UNKNOWN, .v_lock = VAR_UNLOCKED };
287 }
288 return tv;
289 } else {
>>> CID 169163: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "s" to "xmemdupz", which dereferences it. (The dereference is assumed on the basis of the 'nonnull' parameter attribute.)
290 return (typval_T) {
291 .v_type = VAR_STRING,
292 .v_lock = VAR_UNLOCKED,
293 .vval = { .v_string = (char_u *)(
294 s_allocated ? (char *)s : xmemdupz(s, len)) },
295 };
|
|
|
|
| |
Still left calls in eval/typval.c and test/unit/eval/helpers.lua. Latter is the
only reason why function did not receive `static` modifier.
|
| |
|
| |
|
|
|
|
| |
Most of files, except for eval.c and eval/* were only processed by perl.
|
|
|
|
|
|
|
| |
Clang complains because memchr has undefined behavior if the ptr is
NULL, even if len==0.
Helped-by: Nikolai Aleksandrovich Pavlov <kp-pav@yandex.ru>
|
| |
|
|
|
|
|
|
|
| |
Problem: Number variables are not 64 bits while they could be.
Solution: Add the num64 feature. (Ken Takata)
https://github.com/vim/vim/commit/22fcfad29276bd5f317faf516637dcd491b96a12
|
|\ |
|
| | |
|
|\| |
|
| | |
|
| |
| |
| |
| |
| |
| | |
Drops comments `// for …` that do not pass linter for them being unmaintainable
and fast to becoming incomplete or even incorrect.
Mention @dedmass
|
| |
| |
| |
| | |
Not needed any longer since p_enc is always utf-8.
|
| |
| |
| | |
Uses the same trick eval/encode does.
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| | |
msgpack-c previously only had MSGPACK_OBJECT_FLOAT, which was a 64-bit
value. Now, 32-bit and 64-bit floats are supported as distinct types,
but we'll simply continue to treat everything as 64-bit types.
|
| |
| |
| |
| | |
Also fixes buffer reusage in setmatches() and complete().
|
| | |
|
| | |
|
|/
|
|
|
| |
Note: this will *still* crash when using API in cases similar to the one
described in first commit. Just it needs different code to reproduce.
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
Also makes if’s less nested.
|
| |
|
| |
|
|
|
|
| |
Rejects leading zeroes and numbers like 1.e+5 (decimal dot with missing number
with signed exponent).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Note: second test does not crash or produce asan errors, even though it should.
|
|
|
|
|
| |
U+007D is officially RIGHT CURLY BRACKET.
U+005D is officially RIGHT SQUARE BRACKET.
|
| |
|
| |
|
| |
|