When building in release mode, gcc generated a maybe-initialized
warning in get_syn_options. The warning is both right and wrong;
there is an execution path where the len variable is not
initialized in the code:
...
int len;
...
for (fidx = ARRAY_SIZE(flagtab); --fidx >= 0; ) {
p = flagtab[fidx].name;
int i;
for (i = 0, len = 0; p[i] != NUL; i += 2, ++len)
if (arg[len] != p[i] && arg[len] != p[i + 1])
break;
// <snip>
}
...
arg = skipwhite(arg + len);
...
The initial for loop will not execute if ARRAY_SIZE(flagtab) == 0,
and thus len will never be initialized. flagtab is a local-static
variable, initialized to a long array of structured data, so
ARRAY_SIZE(flagtab) can't be 0.
However, gcc doesn't recognize ARRAY_SIZE(flagtab) as a constant.
There are any number of reasons this could happen. In any case,
the message can be fixed with a len=0 before the first for loop.
In addition to the above warning, I've labeled flagtab and
first_letters as const. They should never change.
closes#7599
Helped-by: oni-link <knil.ino@gmail.com>
Freeing `dirname` was first introduced by a code refactoring from `ex_helptags()` to `do_helptags()` (`vim-patch:7.4.1551`)(#4648) and later removed by `vim-patch:7.4.1562`(#4660).
Only problem with that is, that the patches were not applied in order so the fixing patch was declared `N/A`.
So `do_helptags()` should have never freed `dirname`.
Problem: Cannot access the arguments of the current function in debug mode.
(Luc Hermitte)
Solution: use get_funccal(). (Lemonboy, closesvim/vim#1432, closesvim/vim#1352)
c7d9eacefa
When compiling with CMAKE_BUILD_TYPE=RelWithDebInfo, several
-Wmaybe-uninitialized warnings are printed. These were thought to
be false positives (#5061); there are no control paths that lead
to an uninitialized value. However, when gcc is run in -O2 mode,
it makes a mistake while generating the necessary logic.
Specifically, for the code:
...
int = 0; // Index of the server whose address equals addr.
for (; i < watchers.ga_len; i++) {
watcher = ((SocketWatcher **)watchers.ga_data)[i];
// <snip>
}
if (i >= watchers.ga_len) {
ELOG("Not listening on %s", addr);
return;
}
...
Gcc generates:
...
<+98>: cmp %ebx, %ebp
<+100>: jg 0x530f13 <server_stop+55>
<+102>: cmp %ebp, ebx
<+104>: jl 0x530f7e <server_stop+162>
...
Normally, the if statement should catch the only control path
where watcher is not assigned: watchers.ga_len <= 0. When
compiled, the assembly lines 98 and 100 correspond to checking if
i < watchers.ga_len, and the lines 102 and 104 correspond to
checking if i >= watchers.ga_len. The assembly seems to compare
ebp (which is watchers.ga_len) with ebx (which is i), and jump
if greater; then do the same comparison and jump if less. This is
where gcc makes a mistake: it flips the order of the cmp
instruction. This means that the REAL behavior is first check if
i < watchers.ga_len and then check if i < watchers.ga_len. Which
means the code inside the if statement is NEVER executed; no
combination of i and watchers.ga_len will ever trigger ELOG().
So not only is this a use of an uninitialized value if
watchers.ga_len == 0 (or technically, if it's less than zero too),
it also clobbers any error detection if the for loop reaches the
last entry (which would normally cause i == watchers.ga_len too).
This commit fixes this issue by adding a bool to keep track of
whether a watcher was found during the loop. This makes gcc
generate the correct code, avoiding both bugs.
Problem: The return value of mode() does not indicate that completion is
active in Replace and Insert mode. (Zhen-Huan (Kenny) Hu)
Solution: Add "c" or "x" for two kinds of completion. (Yegappan Lakshmanan,
closesvim/vim#1397) Test some more modes.
e90858d022
The flag enables the current local directory set by ":lcd" to be saved
to views which is the current default behaviour. The option can be
removed to disable this behaviour.
closes#7435
vim-patch:8.0.1289
Make the Windows impl closer to Vim os_win32.c, and the Unix impl closer
to Vim os_unix.c.
Outcomes:
- Do not send negative fd to close(). ref #4806#4772#6860
- Fallback return-value is now correct in (hopefully) all cases.
- unix: check S_ISXXX instead of relying on os_open (which can fail for
irrelevant reasons). buf_write() expects NODE_WRITABLE for character
devices such as /dev/stderr. 96f834a842
Anything claiming to be an xterm gets DECSCUSR. This is the only
reasonable choice unless/until we get more reliable detection (#7490).
ref #6997closes#7550
Problem: Crash when 'fileformat' is forced to "dos" and the first line in
the file is empty and does not have a CR character.
Solution: Don't check for CR before the start of the buffer.
2aa5f696b9
* vim-patch:8.0.0245
Problem: The generated zh_CN.cp936.po message file is not encoded properly.
Solution: Instead of using zh_CN.po as input, use zh_CN.UTF-8.po.
16038d50c4
* vim-patch:8.0.0248
Problem: vim_strcat() cannot handle overlapping arguments.
Solution: Use mch_memmove() instead of strcpy(). (Justin M Keyes,
closesvim/vim#1415)
45600ce8f2
Integer is a 64-bit type so using %d can produce incorrect results.
test/functional/api/highlight_spec.lua @ 35: highlight api nvim_get_hl_by_id
...W7Xi/neovim-0.2.1/test/functional/api/highlight_spec.lua:46: Expected objects to be the same.
Passed in:
(string) 'Invalid highlight id: 7671724'
Expected:
(string) 'Invalid highlight id: 30000'
Doc for UV_PROCESS_DETACHED in uv.h mentions:
> child process will still keep the parent's event loop alive unless
> the parent process calls uv_unref() on the child's process handle.
ref #3944
This way code will be easier to adapt to handling (partially) non-expressions
like :let lvalue part or :function definitions, and that would be needed in the
future both for proper completion support and for the Ex commands parser.
Problem: When setting wildoptions=tagfile the completion context is not set
correctly. (desjardins)
Solution: Check for EXPAND_TAGS_LISTFILES. (Christian Brabandt, closesvim/vim#1399)
ba47b51ff8
Problem: Completion of user defined functions is not covered by tests.
Solution: Add tests. Also test various errors of user-defined commands.
(Dominique Pelle, closesvim/vim#1413)
65c836e600
Problem: No command line completion for :cexpr, :cgetexpr, :caddexpr, etc.
Solution: Make completion work. (Yegappan Lakshmanan) Add a test.
2b2207ba69
Problem: The test for patch 8.0.0224 misses the CR characters and passes
even without the fix. (Christian Brabandt)
Solution: Use double quotes and \<CR>.
1695f99d08
Problem: When 'fileformats' is changed in a BufReadPre auto command, it
does not take effect in readfile(). (Gary Johnson)
Solution: Check the value of 'fileformats' after executing auto commands.
(Christian Brabandt)
7a2699e868
