Problem: Several win_T fields are declared as "int" or "char" but are
used strictly as boolean flags with TRUE/FALSE values. The
integer types obscure the boolean intent and are wider than
needed.
Solution: Change the following win_T members to bool (stdbool.h) and
update their assignments from TRUE/FALSE to true/false
accordingly.
The following conversions have been done:
- int -> bool (10 members):
w_set_curswant, w_botfill, w_old_botfill, w_do_win_fix_cursor,
w_popup_fixed, w_border_highlight_isset, w_cline_folded,
w_redr_status, w_arg_idx_invalid, w_has_scrollbar
- char -> bool (4 members):
w_topline_was_set, w_ru_empty, w_fold_manual, w_foldinvalid
No existing code compares these members against TRUE/FALSE explicitly or
uses ++/-- / bitwise ops on them, so only plain assignments are
affected.
Excluded:
- w_locked (recursion counter with ++/--),
- w_want_scrollbar (may hold -1 from dict_get_bool),
- w_winbar_height (used in arithmetic and exposed as number via
getwininfo()).
related: #20005
closes: #20008
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Signed-off-by: Hirohito Higashi <h.east.727@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Currently `colnr_T` and `int` and the same type, so casting
`int *` to `colnr_T *` is redundant. Additionally, even if
they are changed to different types in the future, these casts
are incorrect as they won't work on big-endian platforms.
Solution: Remove the casts. Also fix two cases of passing false instead
of 0 to an integer argument (zeertzjq).
related: #19672
closes: #19907
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: 'linebreak' may lead to wrong Visual block highlighting when
end char occupies multiple cells (after 7.4.467).
Solution: Exclude 'linebreak' from the ending column instead of setting
'virtualedit' temporarily (zeertzjq).
fixes: #19898closes: #19900
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: When virtualedit is set to all, the cursor is supposed to be
permitted to reside anywhere, including on the virtual space
beyond the end of the buffer's text. Switching modes triggered
a routine that "fixed" a cursor that was past the end of the
line by shifting it back to the last actual character in the
line and compensating with a virtual column offset. While
visually identical, this re-encoding changed the underlying
byte index, causing position-reporting functions to return
inconsistent values after a mode change.
Solution: Skip this coordinate adjustment when virtual editing is fully
enabled. By treating the line terminator as a valid, stable
position, the cursor’s internal representation remains
unchanged when entering or exiting Visual mode, ensuring
consistent coordinate reporting. Add a regression test to
check this functionality.
(McAuley Penney)
fixes: #16276closes: #19009
Signed-off-by: McAuley Penney <jacobmpenney@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: getregionpos() depends on 'linebreak' setting
Solution: Reset linebreak setting temporarily (McAuley Penney)
When a line is wrapped on word boundaries, getregionpos() may report a
different end column for a visual block than the cursor position used to
define the selection.
Update the blockwise calculation in getregionpos() to use the same
wrapping assumptions as visual block mode, so the reported region
matches the selection boundaries.
Add a regression test that forces wrapping and checks that the end
position stays consistent under "setlocal wrap" and "setlocal
linebreak".
closes: #19006
Signed-off-by: McAuley Penney <jacobmpenney@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: clipboard provider does not respect 'clipboard' option
(Satoru Kitaguchi, after v9.1.1972)
Solution: make clipboard provider register respect "unnamed/unnamedplus"
from the 'clipboard' option value
fixes: #18930closes: #18952
Signed-off-by: Foxe Chen <chen.foxe@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Generating prototype files does not work on all platforms
Solution: Rework prototypes generation using python instead of cproto,
enable it in CI to test it for each PR (Hirohito Higashi).
closes: #18045
Signed-off-by: Hirohito Higashi <h.east.727@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Not using const qualifier
Solution: Mark the opchars array const
closes: #18196
Signed-off-by: Damien Lejay <damien@lejay.be>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Various typos in the code, redundant and strange use of
:execute in test_ins_complete.vim (after 9.1.1315).
Solution: Fix typos in the code and in the documentation, use the
executed command directly (zeertzjq).
closes: #17143
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: ins_str() is inefficient by calling STRLLEN()
Solution: refactor ins_str() to take a length argument
and let all callers provide the correct length
when calling ins_str() (John Marriott)
closes: #16711
Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: heap-buffer-overflow with visual mode when
using :all, causing Vim trying to access beyond end-of-line
(gandalf)
Solution: Reset visual mode on :all, validate position in gchar_pos()
and charwise_block_prep()
This fixes CVE-2025-22134
Github Advisory:
https://github.com/vim/vim/security/advisories/GHSA-5rgf-26wj-48v8
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: various vartabstop and shiftround bugs when shifting lines
Solution: Fix the bugs, add new tests for shifting lines in various ways
(Gary Johnson)
fixes: #14891closes: #16193
Signed-off-by: Gary Johnson <garyjohn@spocom.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Coverity warns about a few potential issues
Solution: Fix those issues (see details below)
1) Fix overflow warning in highlight.c
This happens because we are comparing int with long
and assign a potential long value to an int, which
could cause an overflow. So add some casts to ensure
the value fits into an int.
2) Fix Overflow warning in shift_line().
This happens because we are performing a division/modulo
operation of a long type by an int type and assign the result
to an int, which could then overflow. So before performing
the operation, trim the long to value to at most max int value,
so that it can't overflow.
3) Fix overflow warning in syn_list_cluster in syntax.c
This is essential the same issue as 1)
4) not checking the return value of vim_mkdir() in spellfile.c
Creating the spell directory could fail. Handle this case
and return early in this case.
5) qsort() may deref a NULL pointer when fuzzy match does not
return a result. Fix this by checking that the accessed growarray
fuzzy_indices actually contains data. If not we can silently skip
the qsort() and related logic.
closes: #15284
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: signed number detection for CTRL-X/A can be improved
(Chris Patuzzo)
Solution: Add the new "blank" value for the 'nrformat' setting. This
will make Vim assume a signed number only if there is a blank
in front of the sign.
(distobs)
fixes: #15033closes: #15110
Signed-off-by: distobs <cuppotatocake@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: block_editing errors out when using <enter>
(Ali Rizvi-Santiago, after v9.1.0274)
Solution: Change ins_len from size_t to int so that the test
if ins_len is negative actually works properly
Add a test, so that this doesn't regress.
fixes: #14960
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Coverity complains about division by zero
Solution: Check explicitly for sw_val being zero
Shouldn't happen, since tabstop value should always be larger than zero.
So just add this as a safety measure.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Left shift is incorrect with vartabstop and shiftwidth=0
Solution: make tabstop_at() function aware of shift direction
(Gary Johnson)
The problem was that with 'vartabstop' set and 'shiftwidth' equal 0,
left shifts using << were shifting the line to the wrong column. The
tabstop to the right of the first character in the line was being used
as the shift amount instead of the tabstop to the left of that first
character.
The reason was that the tabstop_at() function always returned the value
of the tabstop to the right of the given column and was not accounting
for the direction of the shift.
The solution was to make tabstop_at() aware of the direction of the
shift and to choose the tabtop accordingly.
A test was added to check this behavior and make sure it doesn't
regress.
While at it, also fix a few indentation/alignment issues.
fixes: #14864closes: #14887
Signed-off-by: Gary Johnson <garyjohn@spocom.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: MS-Windows: compiler warning for size_t to int conversion
Solution: Add a few type casts to resolve warning on Windows
(Mike Williams)
closes: #14884
Signed-off-by: Mike Williams <mrmrdubya@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: getregionpos() doesn't handle one char selection.
Solution: Handle startspaces differently when is_oneChar is set.
Also add a test for an exclusive charwise selection with
multibyte chars (zeertzjq)
closes: #14825
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: getregionpos() wrong with blockwise mode and multibyte.
Solution: Use textcol and textlen instead of start_vcol and end_vcol.
Handle coladd properly (zeertzjq).
Also remove unnecessary buflist_findnr() in add_regionpos_range(), as
getregionpos() has already switched buffer.
closes: #14805
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: block_editing errors out when using del
(@Jamarley)
Solution: Change ins_len from size_t to int and
properly check that it doesn't become negative
There is a check in os.c that verifies that `ins_len` does not become
negative:
```
if (pre_textlen >= 0 && (ins_len = len - pre_textlen - offset) > 0)
```
However this only works, if ins_len can actually become negative and
unfortunately, ins_len has been declared as `size_t` so instead of
becoming negative it will wrap around and be very large.
So let's define it as integer, after which the condition above
properly catches this condition.
fixes: #14734closes: #14735
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: ops.c code uses too many strlen() calls
Solution: Refactor code and remove more strlen() calls
(John Marriott)
closes: #14598
Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: MS-Windows: a few compiler warnings
Solution: Change variable types to resolve compiler warnings
(Mike Williams)
Windows compiles were reporting a few size_t to signed integer
conversion warnings that can be resolved by changing the variable
declarations to be size_t to start with.
closes: #14429
Signed-off-by: Mike Williams <mrmrdubya@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Coverity reports dead code.
Solution: Remove the dead code. Also fix a mistake in ml_get_pos_len()
and update some comments (zeertzjq).
closes: #14189
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
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: using "C" and 've=all' set, doesn't include composing chars
when changing a line, keeps the composing chars for whatever
is typed afterwards.
Solution: Use mb_head_off() and mb_ptr2len() instead of mb_tail_off().
(zeertzjq)
closes: #14083
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: hard to get visual region using Vim script
Solution: Add getregion() Vim script function
(Shougo Matsushita, Jakub Łuczyński)
closes: #13998closes: #11579
Co-authored-by: =?UTF-8?q?Jakub=20=C5=81uczy=C5=84ski?= <doubleloop@o2.pl>
Co-authored-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Signed-off-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: upper-case of ß should be U+1E9E (CAPITAL LETTER SHARP S)
(fenuks)
Solution: Make gU, ~ and g~ convert the U+00DF LATIN SMALL LETTER SHARP S (ß)
to U+1E9E LATIN CAPITAL LETTER SHARP S (ẞ), update tests
(glepnir)
This is part of Unicode 5.1.0 from April 2008, so should be fairly safe
to use now and since 2017 is part of the German standard orthography,
according to Wikipedia:
https://en.wikipedia.org/wiki/Capital_%E1%BA%9E#cite_note-auto-12
There is however one exception: UnicodeData.txt for U+00DF
LATIN SMALL LETTER SHARP S does NOT define U+1E9E LATIN CAPITAL LETTER
SHARP S as its upper case version. Therefore, toupper() won't be able
to convert from lower sharp s to upper case sharp s (the other way
around however works, since U+00DF is considered the lower case
character of U+1E9E and therefore tolower() works correctly for the
upper case version).
fixes: #5573closes: #14018
Signed-off-by: glepnir <glephunter@gmail.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 ac709e2fc0
(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: Overflow logic requires long long
Solution: Define vimlong_T data type to make life easier
for porters
closes: #13598
Signed-off-by: Ernie Rael <errael@raelity.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: INT overflow logic can be simplified
Solution: introduce trim_to_int() function
closes: #13556
Signed-off-by: Ernie Rael <errael@raelity.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: prevent overflow in indenting
Solution: use long long and remove cast to (int)
The shiftwidth option values are defined as being long. However, when
calculating the actual amount of indent, we cast down to (int), which
may cause the shiftwidth value to become negative and later it may even
cause Vim to try to allocate a huge amount of memory.
We already use long and long long variable types to calculate the indent
(and detect possible overflows), so the cast to (int) seems superfluous
and can be safely removed. So let's just remove the (int) cast and
calculate the indent using longs.
Additionally, the 'shiftwidth' option value is also used when determining
the actual 'cino' options. There it can again cause another overflow, so
make sure it is safe in parse_cino() as well.
fixes: #13554closes: #13555
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Coverity warns for another overflow in shift_line()
Solution: Test for INT_MAX after the if condition, cast integer values
to (long long) before multiplying.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Michael Henry <vim@drmikehenry.com>
Signed-off-by: Ernie Rael <errael@raelity.com>
Problem: [security]: overflow in shift_line
Solution: allow a max indent of INT_MAX
[security]: overflow in shift_line
When shifting lines in operator pending mode and using a very large
value, we may overflow the size of integer. Fix this by using a long
variable, testing if the result would be larger than INT_MAX and if so,
indent by INT_MAX value.
Special case: We cannot use long here, since on 32bit architectures (or
on Windows?), it typically cannot take larger values than a plain int,
so we have to use long long count, decide whether the resulting
multiplication of the shiftwidth value * amount is larger than INT_MAX
and if so, we will store INT_MAX as possible larges value in the long
long count variable.
Then we can safely cast it back to int when calling the functions to set
the indent (set_indent() or change_indent()). So this should be safe.
Add a test that when using a huge value in operator pending mode for
shifting, we will shift by INT_MAX
closes: #13535
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: TextChangedI may not always trigger
Solution: trigger it in more cases: for insert/
append/change operations, and when
opening a new line,
fixes: #13367closes: #13375
Signed-off-by: Christian Brabandt <cb@256bit.org>
Signed-off-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Problem: potential buffer overflow in PBYTE macro
Solution: Check returned memline length
closes: #13083
the PBYTE macro is used to put byte c at a position lp of the returned
memline. However, in case of unexpected errors ml_get_buf() may return
either "???" or an empty line in which case it is quite likely that we
are causing a buffer overrun.
Therefore, switch the macro PBYTE (which is only used in ops.c anyhow)
to a function, that verifies that we will only try to access within the
given length of the buffer.
Also, since the macro is only used in ops.c, move the definition from
macros.h to ops.c
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: The did_set_string_option function is too long.
Solution: Split off functionality to individual functions. (Yegappan
Lakshmanan, Lewis Russell, closes#11904)
Problem: Solution for "!!sort" in closed fold is not optimal.
Solution: Use a different range instead of the subtle difference in handling
a range with an offset. (issue #11487)
Hirohito Higashi
zeertzjq
McAuley Penney
Foxe Chen
phanium
Damien Lejay
John Marriott
Christian Brabandt
Gary Johnson
distobs
Mike Williams
Shougo Matsushita
glepnir
Keith Thompson
Ernie Rael
Bram Moolenaar
Yegappan Lakshmanan