Problem : Assigned value is garbage or undefined @ 12578.
Diagnostic : Multithreading issue.
Rationale : Error can only occur if global `provider_call_nesting` is
changed while function is executing.
Resolution : Use local copy of global.
Problems : Null pointer argument in call to memory copy function
@ 6465.
Null pointer argument in call to memory copy function
@ 6475.
Diagnostic : Multithreading issues.
Rationale : Problem occurs if globals `enc_utf8` and `enc_dbcs` are
modified while function is executing.
Resolution : Use local copy of globals.
Problem : Dereference of null pointer @ 18841.
Diagnostic : False positive.
Rationale : Suggested error path takes `reanimate` branch at 18827,
assigning `rettv = current_funccal->rettv`. Then,
inmediately after, it supposes rettv is null, which cannot
happen, since current_funccal->rettv should always be non
null.
Resolution : Assert current_funccal->rettv non null.
Problem : Out-of-bound array access @ 18737.
Diagnostic : False positive.
Rationale : Situation is intentional. `dictitem_T` is a prefix all dict
items whill share, but actual size of each item will be
different depending on its key length. `di_key` array field
is declared of size 1 just to have a field name, but real
size will vary for each item.
Resolution : Make analyzer ignore it.
This could be refactored to use C99-allowed variable length
arrays, but eval.c is bound to dissappear, so no effort is
done in that sense.
Problem : Out-of-bound array access @ 18429.
Diagnostic : False positive.
Rationale : Situation is intentional. `dictitem_T` is a prefix all dict
items whill share, but actual size of each item will be
different depending on its key length. `di_key` array field
is declared of size 1 just to have a field name, but real
size will vary for each item.
Resolution : Make analyzer ignore it.
This could be refactored to use C99-allowed variable length
arrays, but eval.c is bound to dissappear, so no effort is
done in that sense.
Problem : Dereference of null pointer @ 18216.
Diagnostic : False positive.
Rationale : `hi` and `done` are static. Intended usage is for the first
call to have idx == 0, so that they are initialized.
Resolution : Assert hi after (optional) initialization.
Problem : Bad free @ 16076.
Diagnostic : Real issue.
Rationale : A non-allocated string is set at 4127, which later on can
be tried to be freed if aborting.
Resolution : Detect particular case (func with empty name) and don't
free in that case.
Another solution (use allocated string) was tried before,
but it produced a leak difficult to solve.
Finally applied solution works, but it produces a new false
positive warning (Np dereference at 13763), deactivated by
`assert(ptrs[i].item->li_next)`.
Problem : Result of operation is garbage or undefined @ 13565.
Diagnostic : Multithreading issue.
Rationale : Problem occurs only if global (static) variable
`item_compare_keep_zero` changes after being used by
`do_sort_uniq` but before being used by `item_compare` or
`item_compare2`.
Resolution : This is not an intra-function problem, as other MI's
before, but rather an inter-function one. Thus, it can't be
solved by using local copy of global. Therefore, we are
forced to do a bit refactoring. We can't simply add a bool
param to item_compare/item_compare2, as they couldn't be
passed to qsort() that way. So, item_compare/item_compare2
are added a bool param and curried versions of them are
added and used in their place.
Problem : Out-of-bound array access @ 5737.
Diagnostic : False positive.
Rationale : Situation is intentional. `dictitem_T` is a prefix all dict
items whill share, but actual size of each item will be
different depending on its key length. `di_key` array field
is declared of size 1 just to have a field name, but real
size will vary for each item.
Resolution : Make analyzer ignore it.
This could be refactored to use C99-allowed variable length
arrays, but eval.c is bound to dissappear, so no effort is
done in that sense.
Problem : Dereference of null pointer @ 2273.
Diagnostic : False positive.
Rationale : Suggested error would happen when assigning an rvalue with
more items than the lvalue. Then we would enter conditional
at:
```
if (lp->ll_li->li_next == NULL) {
/* Need to add an empty item. */
list_append_number(lp->ll_list, 0);
}
lp->ll_li = lp->ll_li->li_next;
```
Analyzer thinks the value assigned to lp->ll_li is still
NULL and is hit on the next iteration.
Resolution : Assert lp->ll_li->li_next is not null anymore after
list_append_number().
Problem : Dereference of null pointer @ 4978.
Diagnostic : False positive.
Rationale : tabline_height() shouldn't be called when a tab doesn't
exist yet (this is, before initialization).
Resolution : Assert function precondition.
Problem : Dereference of null pointer @ 4512.
Diagnostic : False positive.
Rationale : Suggested error path implies `fr == NULL` after 4504.
That's not possible, because:
- curfr and curfr->next must be both nonnull, as we are
dragging the divider between the two.
- after conditional, fr is one of those two (the one that
grows).
Resolution : Assert fr.
Problem : Dereference of null pointer @ 2196.
Diagnostic : False positive.
Rationale : Suggested error path implies `frp->child == NULL` while
being under condition `frp2->fr_layout == frp->fr_layout`,
which is impossible:
- If frp2 is frp's parent, then frp2's layout is FR_COL or
FR_ROW;
- if frp->child is NULL, the frp's layout is FR_LEAF.
- Therefore, they can't be equal.
Resolution : Assert frp->child not null.
Problem : Dereference of null pointer @ 1268.
Diagnostic : False positive.
Rationale : Suggested error path implies current window's frame to be
the only child of its parent, which is ruled out by
`if (firstwin == lastwin) {` check at the beginning.
Resolution : Assert another child remains after removing current frame.
Strictly, assert is only needed in false branch of
conditional, but we add it the same in the true branch to
reduce reader surprise.
Several forms of a single assert after
`if (firstwin == lastwin) {` were tried, but analyzer
cannot follow implications that way.
Problem : Uninitialized argument value @ 2798.
Diagnostic : Real issue.
Rationale : Tags doesn't have to have a kind. When they have one, both
`tp.tagkind` and `tp.tagkind_end` are nonnull. But when
they don't, `tp.tagkind` will we null (but defined), while
`tp.tagkind_end` will be undefined.
Therefore, reported invocation is indeed using a garbage
value for a tag with no kind.
Problem doesn't have consequences because `add_tag_field()`
doesn't use `end` param if `start` param is null.
Resolution : Don't use `tp.tagkind_end` if `tp.tagkind` is null.
Problem : Dereference of null pointer @ 2399.
Diagnostic : Multithreading issue.
Rationale : Error can only occur if global `g_do_tagpreview` changes
while the function is executing.
Resolution : Use local copy of global var.
Problems : Assigned value is garbage or undefined @ 2191.
Uninitialized argument value @ 2796.
Diagnostic : False positives.
Rationale : Both problems share the same cause.
Error happens in get_tags(), if parse_match() fails because
of parse_tag_line() failing before. Then, `tp` is not
correctly initialized and subsequent code accesses garbage
values.
This is not really possible, as parse_tag_line() should not
fail after find_tags() has been successful.
That is because find_tags() already does tag line parsing,
using parse_tag_line() itself for it (or a quicker
alternative that should produce same result). That's why
return value of parse_match() is ignored, and subsequent
code assumes it is successful.
Resolution : Assert parse_match() always successful.
These use autoloaded vimscript to replace the provider_call/provider_has
functions, moving the implementation of providers to pure vimscript(we lose
nothing since vimscript can also call msgpack-rpc functions).
When calling the rpcrequest function from a provider, temporarily switch to the
caller scope. This is required for compatibility with legacy plugins, because
they may depend on scope information that changes when "leaving" the C stack to
enter the vimscript stack.
The function mch_print_begin() returns early in case of an
error, but without freeing allocated memory.
To fix this, use stack allocation instead of heap allocation
for the variables res_prolog, res_encoding, res_cidfont and
res_cmap.
Problem : Dead assignment @ 1037.
Diagnostic : Harmless issue.
Rationale : `tab_corr` is in effect unused after signaled point.
Previous code using it after that point was removed at
24ebb018e2.
Resolution : Remove dead assignment. As only one usage remains, remove
variable and inline the only usage.
Problem : Double free @ 5213.
Diagnostic : False positive.
Rationale : Suggested error path contains two consecutive invocations
of `ends_excmd(*p)` having different results, which is not
possible. First invocation is before the while loop. Second
invocation is the while loop condition itsef.
Resolution : Refactor while loop into do-while loop. That removes the
impossible path from analysis, and, in addition, is a bit
more efficient.
Problem : Uninitialized argument value @ 2863.
Diagnostic : Multithreading issue.
Rationale : Error can only occur if global `syn_time_on` is changed
while the function is executing.
Resolution : Use local copy of gloval var.
Problem : Assigned value is garbage or undefined @ 12526.
Diagnostic : Multithreading issue.
Rationale : Error only occurs if global has_mbyte is modified while
function is executing.
Resolution : Use local copy of global.
