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)
Problem: Cursor in wrong position with Visual substitute.
Solution: When restoring 'linebreak' mark the virtual column as invalid.
(closes#11309, closes#11311)
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)
Problem: Reproducing memory access errors can be difficult.
Solution: When testing, copy each line to allocated memory, so that valgrind
can detect accessing memory before and/or after it. Fix uncovered
problems.
Problem: smart/C/lisp indenting is optional, which makes the code more
complex, while it only reduces the executable size a bit.
Solution: Graduate FEAT_CINDENT, FEAT_SMARTINDENT and FEAT_LISP.
