Problem: Filetype may be undetected when a SwapExists autocommand sets
filetype in another buffer.
Solution: Make filetype detection state buffer-specific. Also fix a
similar problem for 'modified' (zeertzjq).
closes: #14344
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: memleak with ex_drop(), NULL dereference
(zeertzjq)
Solution: revert back to ex_rewind(), use curbuf instead of buf
fixes: #14246closes: #14251
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: :drop tries to :rewind the argumentlist, which results in E37
(after v9.1.0046)
Solution: instead of calling ex_rewind(), call open_buffer() only when
re-using the initial empty buffer
fixes: #14219closes: #14220
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: More code can use ml_get_buf_len() instead of STRLEN().
Solution: Change more STRLEN() calls to ml_get_buf_len(). Also do not
set ml_line_textlen in ml_replace_len() if "has_props" is set,
because "len_arg" also includes the size of text properties in
that case. (zeertzjq)
closes: #14183
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Cannot keep a buffer focused in a window
(Amit Levy)
Solution: Add the 'winfixbuf' window-local option
(Colin Kennedy)
fixes: #6445closes: #13903
Signed-off-by: Colin Kennedy <colinvfx@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: qsort() comparison functions should be transitive
Solution: Do not subtract values, but rather use explicit comparisons
Improve qsort() comparison functions
There has been a recent report on qsort() causing out-of-bounds read &
write in glibc for non transitive comparison functions
https://www.qualys.com/2024/01/30/qsort.txt
Even so the bug is in glibc's implementation of the qsort() algorithm,
it's bad style to just use substraction for the comparison functions,
which may cause overflow issues and as hinted at in OpenBSD's manual
page for qsort(): "It is almost always an error to use subtraction to
compute the return value of the comparison function."
So check the qsort() comparison functions and change them to be safe.
closes: #13980
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Things that temporarily change/restore curwin/buf (e.g:
win_execute, some autocmds) may break assumptions that
curwin/buf is the cmdwin when "cmdwin_type != 0", causing
issues.
Solution: Expose the cmdwin's real win/buf and check that instead. Also
try to ensure these variables are NULL if "cmdwin_type == 0",
allowing them to be used directly in most cases without
checking cmdwin_type. (Sean Dewar)
Alternatively, we could ban win_execute in the cmdwin and audit all places that
temporarily change/restore curwin/buf, but I didn't notice any problems arising
from allowing this (standard cmdwin restrictions still apply, so things that may
actually break the cmdwin are still forbidden).
closes: #12819
Signed-off-by: Sean Dewar <seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: :drop does not re-use empty buffer
(Rocco Mao)
Solution: Make :drop re-use an empty buffer
(Rocco Mao)
fixes: #13851closes: #13881
Signed-off-by: Rocco Mao <dapeng.mao@qq.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: is*() and to*() function may be unsafe
Solution: Add SAFE_* macros and start using those instead
(Keith Thompson)
Use SAFE_() macros for is*() and to*() functions
The standard is*() and to*() functions declared in <ctype.h> have
undefined behavior for negative arguments other than EOF. If plain char
is signed, passing an unchecked value from argv for from user input
to one of these functions has undefined behavior.
Solution: Add SAFE_*() macros that cast the argument to unsigned char.
Most implementations behave sanely for negative arguments, and most
character values in practice are non-negative, but it's still best
to avoid undefined behavior.
The change from #13347 has been omitted, as this has already been
separately fixed in commit ac709e2fc0db6d31abb7da96f743c40956b60c3a
(v9.0.2054)
fixes: #13332closes: #13347
Signed-off-by: Keith Thompson <Keith.S.Thompson@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: POSIX function name in exarg struct causes issues
on OpenVMS
Solution: Rename getline member in exarg struct to ea_getline,
remove isinf() workaround for VMS
There are compilers that do not treat well POSIX functions - like
getline - usage in the structs.
Older VMS compilers could digest this... but the newer OpenVMS compilers
( like VSI C x86-64 X7.4-843 (GEM 50XB9) ) cannot deal with these
structs. This could be limited to getline() that is defined via
getdelim() and might not affect all POSIX functions in general - but
avoiding POSIX function names usage in the structs is a "safe side"
practice without compromising the functionality or the code readability.
The previous OpenVMS X86 port used a workaround limiting the compiler
capabilities using __CRTL_VER_OVERRIDE=80400000
In order to make the OpenVMS port future proof, this pull request
proposes a possible solution.
closes: #13704
Signed-off-by: Zoltan Arpadffy <zoltan.arpadffy@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: buffer-overflow in ex_substitute
Solution: clear memory after allocating
When allocating the new_start pointer in ex_substitute() the memory
pointer points to some garbage that the following for loop in
ex_cmds.c:4743 confuses and causes it to accessing the new_start pointer
beyond it's size, leading to a buffer-overlow.
So fix this by using alloc_clear() instead of alloc(), which will
clear the memory by NUL and therefore cause the loop to terminate
correctly.
Reported by @henices, thanks!
closes: #13596
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in ex_substitute
Solution: always allocate memory
closes: #13552
A recursive :substitute command could cause a heap-use-after free in Vim
(CVE-2023-48706).
The whole reproducible test is a bit tricky, I can only reproduce this
reliably when no previous substitution command has been used yet
(which is the reason, the test needs to run as first one in the
test_substitute.vim file) and as a combination of the `:~` command
together with a :s command that contains the special substitution atom `~\=`
which will make use of a sub-replace special atom and calls a vim script
function.
There was a comment in the existing :s code, that already makes the
`sub` variable allocate memory so that a recursive :s call won't be able
to cause any issues here, so this was known as a potential problem
already. But for the current test-case that one does not work, because
the substitution does not start with `\=` but with `~\=` (and since
there does not yet exist a previous substitution atom, Vim will simply
increment the `sub` pointer (which then was not allocated dynamically)
and later one happily use a sub-replace special expression (which could
then free the `sub` var).
The following commit fixes this, by making the sub var always using
allocated memory, which also means we need to free the pointer whenever
we leave the function. Since sub is now always an allocated variable,
we also do no longer need the sub_copy variable anymore, since this one
was used to indicated when sub pointed to allocated memory (and had
therefore to be freed on exit) and when not.
Github Security Advisory:
https://github.com/vim/vim/security/advisories/GHSA-c8qm-x72m-q53q
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: overflow with count for :s command
Solution: Abort the :s command if the count is too large
If the count after the :s command is larger than what fits into a
(signed) long variable, abort with e_value_too_large.
Adds a test with INT_MAX as count and verify it correctly fails.
It seems the return value on Windows using mingw compiler wraps around,
so the initial test using :s/./b/9999999999999999999999999990 doesn't
fail there, since the count is wrapping around several times and finally
is no longer larger than 2147483647. So let's just use 2147483647 in the
test, which hopefully will always cause a failure
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: heap-buffer-overflow in vim_regsub_both
Solution: Disallow exchanging windows when textlock is active
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: RedrawingDisabled not used consistently.
Solution: Avoid RedrawingDisabled going negative. Set RedrawingDisabled in
win_split_ins(). (closes#11961)
Problem: Search error message doesn't show used pattern.
Solution: Pass the actually used pattern to where the error message is
given. (Rob Pilling, closes#11742)
Problem: Shell command with just space gives strange error.
Solution: Skip white space at start of the argument. (Christian Brabandt,
Shane-XB-Qian, closes#11515, closes#11495)
Problem: ":!" doesn't do anything but does update the previous command.
Solution: Do not have ":!" change the previous command. (Martin Tournoij,
closes#11372)
Problem: Too many #ifdefs.
Solution: Graduate the +cmdwin feature. Now the tiny and small builds are
equal, drop the small build. (Martin Tournoij, closes#11268)
Problem: When using powershell input redirection does not work.
Solution: Use a different shell command for powershell. (Yegappan
Lakshmanan, closes#11257)
Problem: The command line takes up space even when not used.
Solution: Allow for 'cmdheight' to be set to zero. (Shougo Matsushita,
closes#10675, closes#940)
