vim_strsave() is replaced by expand_env_save_opt(), which expands ~ for
convenience:
:profile start ~/.nvim/prof.log
Prior to this change you had to specify an absolute path.
All these issues are false positives that result from coverity's
inability to properly follow arithmetic implications in expressions
using some macros. Redefining macros another way to make arithmetic
implications clearer fixes the issues.
- Properly save job event deferring state for recursive calls
- Disable breakcheck while running. Breakcheck can invoke job callbacks
in unexpected places.
Regarding |script-here|: despite being a language agnostic piece of
advice, it was in `if_perl.txt`. Regardless, we now only have one
support for one legacy plugin interface, so put it in `if_pyth.txt`
Rubycomplete requires 'if_ruby', which has never been in Neovim. Because
of this, remove some mentions of it from the docs, but keep the actual
plugin untouched (as to avoid unneeded maintainence costs). It has a
call to `has('ruby')`, so it will still fall back to syntax completion.
Fixes the handling of the initial input lines of a test script by simply
skipping all initial empty lines.
Helped-by: Florian Walch <florian@fwalch.com>
Suggested-by: Florian Walch <florian@fwalch.com>
Reported by @fourjay, a codepath that causes event_poll() to run before
event_init() will trigger a segfault as the events list will not have
been initialized. Exiting immediately from event_init() causes nvim to
hang, so just exit before running the events.
fixes#2339
Resolves#1753.
https://code.google.com/p/vim/source/detail?r=v7-4-399
Reviewed-by: Felipe Oliveira Carvalho <felipekde@gmail.com>
Helped-by: David Bürgin <676c7473@gmail.com>
Helped-by: Scott Prager <splinterofchaos@gmail.com>
Helped-by: Michael Reed <m.reed@mykolab.com>
Helped-by: Felipe Oliveira Carvalho <felipekde@gmail.com>
event_poll() always leaves the libuv I/O loop after one iteration. The
duration for how long the loop polls for I/O is given by the shortest
timeout of all active timers. Is no timer active, I/O is/could be polled
indefinitely.
To make sure our timer is still active when I/O polling begins,
a prepare handle is used to start the timer right before the polling.
But by only using a timer that restarts after its timeout was reached,
we also can assure that polling is done with (nearly) the same finite
timeout.
For a short explanation how the I/O loop is working, see
http://docs.libuv.org/en/latest/design.html#the-i-o-loop.
Problem : Dereference of null pointer @ 1769.
Diagnostic : Real issue.
Rationale : It seems buffer could be null. Not sure, though.
Resolution : Check for buffer null.
This resolution was chosen as it will always work.
But it could be that buffer can't really be null at that
point. autocmd_win is ruled out by close_window, so that
can't be the case. I'm not sure if other windows without
buffers are possible, so leaving it this way.
If it's confirmed buffer can't be null, resolution through
an assert would be possible and this would be FP, not RI.
Problem : Dead initialization @ 1119.
Diagnostic : Real issue.
Rationale : `obj` is immediately assigned another value through
GET_CONFIG_VALUE macro.
Resolution : Don't initialize.
Helped-by: oni-link <knil.ino@gmail.com>
Problem : Dead initialization @ 1109.
Diagnostic : Real issue.
Rationale : `obj` is immediately assigned another value through
GET_CONFIG_VALUE macro.
Resolution : Don't initialize.
Helped-by: oni-link <knil.ino@gmail.com>
Problem : Dereference of null pointer @ 1053.
Diagnostic : Real issue.
Rationale : Branch "Exiting focused terminal" can actually be executed
when term is NULL.
Resolution : Guard branch with term check.
Problem : Use-after-free @ 15081.
Diagnostic : Multithreading issue.
Rationale : `get_dict_callback` can return NULL on two different
cases: 1) when the dict doesn't contain the given key;
this case is not considered an error. 2) when the key
exists but there's some problem with its value; this is
considered an error.
Then, code calling `get_dict_callback` in
`common_job_callbacks`, as well as code calling
`common_job_callbacks`, uses `did_emsg` to distinguish
between error/non-error cases.
Suggested error path presumes an error condition within
`common_job_callbacks`, with `did_emsg` being true, but
then being false just after returning to calling code in
`f_termopen`.
That, clearly, could only happen if another thread run in
between those points.
Resolution : Refactor `get_dict_callback` and `common_job_callbacks`, so
that they clearly distinguish between error/non-error
situations, without recurring to globals.
Problem : Dereference of null pointer @ 10812.
Diagnostic : False positive.
Rationale : `args->lv_first` can't be NULL, as we have just stated
above that that there's at least one item.
Resolution : Assert.
