| Commit message (Collapse) | Author | Age |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: Unused assignments when checking the value of 'listchars'.
Solution: Loop only once when just checking the value. Add a test to
check that this change doesn't cause double-free.
closes: vim/vim#13559
https://github.com/vim/vim/commit/00624a2fa08d04bdded240d474e9cfdc193dbe10
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: File info disappears immediately when 'cmdheight' has just
decreased due to switching tabpage and 'shortmess' doesn't
contain 'o' or 'O'.
Solution: Make sure msg_row isn't smaller than cmdline_row.
fixes: vim/vim#13560
closes: vim/vim#13561
https://github.com/vim/vim/commit/40ed6711bd385051021691980e8ce16375b4b510
|
| | | |
|
| | |
| |
| | |
ENOTSUP case is present in vim, but doesn't appear to have included here.
|
| | |
| |
| |
| |
| |
| |
| | |
skipwhite was iterating over the input twice and scanning for the null
byte character with strlen. this is redundant, because it's already
covered by ascii_iswhite that accepts only space or tab character.
Co-authored-by: ii14 <ii14@users.noreply.github.com>
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: [security]: use-after-free in ex_substitute
Solution: always allocate memory
closes: vim/vim#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
https://github.com/vim/vim/commit/26c11c56888d01e298cd8044caf860f3c26f57bb
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: Vim9: cannot use \=expr in :substitute.
Solution: Compile the expression into instructions and execute them when
invoked.
https://github.com/vim/vim/commit/4c13721482d7786f92f5a56e43b0f5c499264b7e
Vim9 script is N/A, including substitute_instr.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
|
| | |\
| | |
| | | |
feat(extmarks): add sign name to extmark "details" array
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: Unable to identify legacy signs when fetching extmarks with
`nvim_buf_get_extmarks()`.
Solution: Add "sign_name" to the extmark detail array.
Add some misc. changes as follow-up to #25724
|
| | |/
| |
| |
| |
| |
| |
| | |
The most general conditions should come before more specific conditions.
For example, `UNIX` options needs to be specified before any
distro-specific options. This way distro specific options takes priority
over the general case in case there's a conflict.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Remove the monolithic Decoration struct. Before this change, each extmark
could either represent just a hl_id + priority value as a inline
decoration, or it would take a pointer to this monolitic 112 byte struct
which has to be allocated.
This change separates the decorations into two pieces: DecorSignHighlight
for signs, highlights and simple set-flag decorations (like spell,
ui-watched), and DecorVirtText for virtual text and lines.
The main separation here is whether they are expected to allocate more
memory. Currently this is not really true as sign text has to be an
allocated string, but the plan is to get rid of this eventually (it can
just be an array of two schar_T:s). Further refactors are expected to
improve the representation of each decoration kind individually. The
goal of this particular PR is to get things started by cutting the
Gordian knot which was the monolithic struct Decoration.
Now, each extmark can either contain chained indicies/pointers to
these kinds of objects, or it can fit a subset of DecorSignHighlight
inline.
The point of this change is not only to make decorations smaller in
memory. In fact, the main motivation is to later allow them to grow
_larger_, but on a dynamic, on demand fashion. As a simple example, it
would be possible to augment highlights to take a list of multiple
`hl_group`:s, which then would trivially map to a chain of multiple
DecorSignHighlight entries.
One small feature improvement included with this refactor itself, is
that the restriction that extmarks cannot be removed inside a decoration
provider has been lifted. These are instead safely lifetime extended
on a "to free" list until the current iteration of screen drawing is done.
NB: flags is a mess. but DecorLevel is useless, this slightly less so
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: [security] use-after-free in qf_free_items
Solution: only access qfpnext, if it hasn't been freed
Coverity discovered a possible use-after-free in qf_free_items. When
freeing the qfline items, we may access freed memory, when qfp ==
qfpnext.
So only access qfpnext, when it hasn't been freed.
https://github.com/vim/vim/commit/567cae2630a51efddc07eacff3b38a295e1f5671
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
runtime(doc): Fix whitespace and formatting of some help files (vim/vim#13549)
https://github.com/vim/vim/commit/596a9f29c83af85ace1a2702c88591851ad14df8
N/A patch:
vim-patch:aabca259fa48
Co-authored-by: h_east <h.east.727@gmail.com>
|
| | | |
|
| | |
| |
| |
| |
| | |
It is less intrusive to silence the warning with a comment instead of a
macro if needed.
|
| | |
| |
| |
| |
| | |
These are only used when running `make lintc` with ENABLE_ASAN_UBSAN
enabled, which is why it wasn't caught by CI.
|
| | |
| |
| |
| |
| |
| | |
Also add _GNU_SOURCE compiler definition for all non MSVC compilers.
Closes https://github.com/neovim/neovim/issues/26087.
|
| | |
| |
| |
| | |
Fix #26135
|
| | |
| |
| |
| |
| | |
Problem: Minimum and maximum signcolumn width is determined each redraw.
Solution: Determine and store 'signcolumn' range when option is set.
|
| | |
| |
| |
| |
| |
| |
| | |
Enable all clang-tidy warnings by default instead of disabling them.
This ensures that we don't miss useful warnings on each clang-tidy
version upgrade. A drawback of this is that it will force us to either
fix or adjust the warnings as soon as possible.
|
| | |
| |
| |
| |
| |
| | |
This requires removing the "Inner expression should be aligned" rule
from clint as it prevents essentially any formatting regarding ternary
operators.
|
| | | |
|
| | |
| |
| |
| |
| | |
- reduce variable scope
- prefer initialization over declaration and assignment
|
| | |
| |
| |
| | |
Biggest change is that uncrustify is silent during linting.
|
| | |
| |
| | |
Fix https://github.com/airblade/vim-gitgutter/issues/875
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Correct MSVC warning suppression. The C4003 warning is issued during
file generation and not for the actual source files.
- Remove non-existent "scripts/pvscheck.sh" file from `lintsh` target.
- Remove spaces inside for loops with uncrustify.
- Point dependencies to use a git tag rather than releases, as releases
might have changes that deviate from the actual source code.
- Automatically update uncrustify config before formatting or linting.
|
| | |\
| | |
| | | |
refactor(sign): move legacy signs to extmarks
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: The legacy signlist data structures and associated functions are
redundant since the introduction of extmark signs.
Solution: Store signs defined through the legacy commands in a hashmap, placed
signs in the extmark tree. Replace signlist associated functions.
Usage of the legacy sign commands should yield no change in behavior with the
exception of:
- "orphaned signs" are now always removed when the line it is placed on is
deleted. This used to depend on the value of 'signcolumn'.
- It is no longer possible to place multiple signs with the same identifier
in a single group on multiple lines. This will now move the sign instead.
Moreover, both signs placed through the legacy sign commands and through
|nvim_buf_set_extmark()|:
- Will show up in both |sign-place| and |nvim_buf_get_extmarks()|.
- Are displayed by increasing sign identifier, left to right.
Extmark signs used to be ordered decreasingly as opposed to legacy signs.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
The sign extension issue has been fixed upstream, so we no longer need
to use our own workaround.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Refactor our implementation of querying for Kitty keyboard protocol
support:
- Remove usage of the "extkeys" term. This is not standard or really
used elsewhere. Use "key encoding" instead
- Replace usages of "CSIu" with "Kitty". "Kitty keyboard protocol" is
vastly more common than "CSIu" now
- Replace the countdown response counter with a simple boolean flag. We
don't actually need a countdown counter because we request the primary
device attributes along with the Kitty keyboard query, so we will
always receive a "terminating event", making a countdown/timer
unnecessary
- Move the CSI response handling into a dedicated function
- Bypass Unibilium for sending key encoding escape sequences. These
sequences are not part of terminfo and do not have any parameters, so
there's no reason to go through Unibilium
|
| | | |
| | |
| | |
| | | |
The test is for the case without 'termsync' because libvterm doesn't
support synchronized output, and it passes without this PR.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: buffer text with composing chars are converted from UTF-8
to an array of up to seven UTF-32 values and then converted back
to UTF-8 strings.
Solution: Convert buffer text directly to UTF-8 based schar_T values.
The limit of the text size is now in schar_T bytes, which is currently
31+1 but easily could be raised as it no longer multiplies the size
of the entire screen grid when not used, the full size is only required
for temporary scratch buffers.
Also does some general cleanup to win_line text handling, which was
unnecessarily complicated due to multibyte rendering being an "opt-in"
feature long ago. Nowadays, a char is just a char, regardless if it consists
of one ASCII byte or multiple bytes.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: [security]: Use-after-free in win_close()
Solution: Check window is valid, before accessing it
If the current window structure is no longer valid (because a previous
autocommand has already freed this window), fail and return before
attempting to set win->w_closing variable.
Add a test to trigger ASAN in CI
https://github.com/vim/vim/commit/25aabc2b8ee1e19ced6f4da9d866cf9378fc4c5a
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: [security] use-after-free from buf_contents_changed()
Solution: block autocommands
https://github.com/vim/vim/commit/41e6f7d6ba67b61d911f9b1d76325cd79224753d
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: buffer-overflow in trunc_string()
Solution: Add NULL at end of buffer
Currently trunc_string() assumes that when the string is too long,
buf[e-1] will always be writeable. But that assumption may not always be
true. The condition currently looks like this
else if (e + 3 < buflen)
[...]
else
{
// can't fit in the "...", just truncate it
buf[e - 1] = NUL;
}
but this means, we may run into the last else clause with e still being
larger than buflen. So a buffer overflow occurs.
So instead of using `buf[e - 1]`, let's just always
truncate at `buf[buflen - 1]` which should always be writable.
https://github.com/vim/vim/commit/3bd7fa12e146c6051490d048a4acbfba974eeb04
vim-patch:9.0.2004: Missing test file
Problem: Missing test file
Solution: git-add the file to the repo
closes: vim/vim#13305
https://github.com/vim/vim/commit/d4afbdd0715c722cfc73d3a8ab9e578667615faa
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: crash with bt_quickfix1_poc when cleaning up
and EXITFREE is defined
Solution: Test if buffer is valid in a window, else close
window directly, don't try to access buffer properties
While at it, increase the crash timeout slightly, so that CI has a
chance to finish processing the test_crash() test.
https://github.com/vim/vim/commit/623ba31821a41acee7e948794e84867680b97885
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: heap use after free in ins_compl_get_exp()
Solution: validate buffer before accessing it
https://github.com/vim/vim/commit/ee9166eb3b41846661a39b662dc7ebe8b5e15139
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: heap-use-after-free in is_qf_win()
Solution: Check buffer is valid before accessing it
https://github.com/vim/vim/commit/fc68299d436cf87453e432daa77b6d545df4d7ed
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: [security]: FPE in adjust_plines_for_skipcol
Solution: don't divide by zero, return zero
Prevent a floating point exception when calculating w_skipcol (which can
happen with a small window when the number option is set and cpo+=n).
Add a test to verify
https://github.com/vim/vim/commit/cb0b99f0672d8446585d26e998343dceca17d1ce
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: [security]: overflow in get_number
Solution: Return 0 when the count gets too large
[security]: overflow in get_number
When using the z= command, we may overflow the count with values larger
than MAX_INT. So verify that we do not overflow and in case when an
overflow is detected, simply return 0
https://github.com/vim/vim/commit/73b2d3790cad5694fc0ed0db2926e4220c48d968
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: [security]: overflow in ex address parsing
Solution: Verify that lnum is positive, before substracting from
LONG_MAX
[security]: overflow in ex address parsing
When parsing relative ex addresses one may unintentionally cause an
overflow (because LONG_MAX - lnum will overflow for negative addresses).
So verify that lnum is actually positive before doing the overflow
check.
https://github.com/vim/vim/commit/060623e4a3bc72b011e7cd92bedb3bfb64e06200
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Problem: [security]: overflow in nv_z_get_count
Solution: break out, if count is too large
When getting the count for a normal z command, it may overflow for large
counts given. So verify, that we can safely store the result in a long.
https://github.com/vim/vim/commit/58f9befca1fa172068effad7f2ea5a9d6a7b0cca
Co-authored-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
https://github.com/vim/vim/commit/ac63787734fda2e294e477af52b3bd601517fa78
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
