Problem: some errors with translation Makefiles
Solution: fix issues
Update src/po/ makefiles after 9.0.2127
* Change how to check `%LANGUAGE%`.
Check it only when needed.
* Add double quotes to where `GETTEXT_PATH` is used.
Before 9.0.2127, this worked: `nmake -f Make_mvc.mak GETTEXT_PATH="\"C:\Program Files\Git\usr\bin\""` (which was a bit tricky.)
9.0.2127 broke this and syntax error occurred.
This doesn't work either in 9.0.2127: `nmake -f Make_mvc.mak GETTEXT_PATH="C:\Program Files\Git\usr\bin"`
With this Commit, this works: `nmake -f Make_mvc.mak GETTEXT_PATH="C:\Program Files\Git\usr\bin"`
* Better error report for the `check` target.
Show the line number of the error. (Imported from vim-jp/lang-ja.)
closes: #13567
Signed-off-by: Ken Takata <kentkt@csc.jp>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: use-after-free in call_dfunc()
Solution: Refresh dfunc pointer
closes: #13571
This Commit fixes a SEGV caused by a use-after-free bug in call_dfunc().
When calling check_ufunc_arg_types() from the call_dfunc() it may cause
def functions to be re-compiled and if there are too many def functions,
the def_functions array will be re-allocated. Which means, that the
dfunc pointer in call_dfunc() now starts pointing to freed memory.
So we need to reset the dfunc pointer after calling
check_ufunc_arg_types().
Let's also add a test, to ensure we do not regress.
Signed-off-by: mityu <mityu.mail@gmail.com>
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Add syntax and filetype plugins for SWIG (Simplified Wrapper Interface
Generator) description files.
The default syntax for .i files highlights comments in a reverse
color scheme which doesn't look well. This syntax builds
on vim's c++ syntax by adding highlighting for common swig
directives and user defined directives. For an alternative
syntax, see vimscript #1247 (which I found after writing this).
closes: #13562
Co-authored-by: Matěj Cepl <mcepl@cepl.eu>
Co-authored-by: Julien Marrec <julien.marrec@gmail.com>
Signed-off-by: Julien Marrec <julien.marrec@gmail.com>
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: translation Makefiles can be improved
Solution: Modified and extended po-related Makefiles and
related files
closes: #13518
Signed-off-by: RestorerZ <restorer@mail2k.ru>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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: #13559
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
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: #13560closes: #13561
Signed-off-by: zeertzjq <zeertzjq@outlook.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: Problem with initializing the length of range() lists
Solution: Set length explicitly when it shouldn't contain any items
range() may cause a wrong calculation of list length, which may later
then cause a segfault in list_find(). This is usually not a problem,
because range_list_materialize() calculates the length, when it
materializes the list.
In addition, in list_find() when the length of the range was wrongly
initialized, it may seem to be valid, so the check for list index
out-of-bounds will not be true, because it is called before the list is
actually materialized. And so we may eventually try to access a null
pointer, causing a segfault.
So this patch does 3 things:
- In f_range(), when we know that the list should be empty, explicitly
set the list->lv_len value to zero. This should happen, when
start is larger than end (in case the stride is positive) or
end is larger than start when the stride is negative.
This should fix the underlying issue properly. However,
- as a safety measure, let's check that the requested index is not
out of range one more time, after the list has been materialized
and return NULL in case it suddenly is.
- add a few more tests to verify the behaviour.
fixes: #13557closes: #13563
Co-authored-by: Tim Pope <tpope@github.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: [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: un-used assignment in do_source_buffer_init
Solution: Remove it
Coverity warns about assigning NULL to line in scriptfile.c:1408,
because right after that assignment, in the next iteration of the loop,
line will be overwritten by the next value from vim_strsave().
And in case this was the last iteration, the line variable is no longer
used until the function returns. So we can safely remove that assignment.
closes: #13547
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: remove dead-condition in ex_class()
Solution: remove the extra condition
The variable is_class must be true once we reach the
,----
| else if (has_static)
`----
in line 1750, because we break out earlier if is_class is false in line
1598 of vim9class.c. And once 'has_static = TRUE', we must be in a
class and there fore is_class is true.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: [security]: avoid double-free
Solution: Only fee plain_font, when it is not the same as bold_font
When plain_font == bold_font and bold_font is not NULL, we may end up
trying to free bold_font again, which already has been freed a few lines
above.
So only free bold_font, when the condition gui.font_can_bold is true,
which means that bold_font is not pointing to plain_font (so it needs to
be freed separately).
Signed-off-by: Christian Brabandt <cb@256bit.org>
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.
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: No test for defining sign without attribute
Solution: Add test for defining sign without attributes
closes: #13544
Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: crash when callback function aborts because of recursiveness
Solution: correctly initialize rettv
Initialize rettv in invoke_popup_callback()
Since v9.0.2030, call_callback may exit early when the callback recurses
too much. This meant that call_func, which would set rettv->v_type =
VAR_UNKNOWN, was not being called.
Without rettv->v_type being explicitly set, it still contained whatever
garbage was used to initialize the stack value in invoke_popup_callback.
This would lead to possible crashes when calling clear_tv(&rettv).
Rather than rely on action at a distance, explicitly initialize rettv's
type to VAR_UNKNOWN so clear_tv can tell nothing needs to be done.
closes: #13495closes: #13545
Signed-off-by: James McCoy <jamessan@jamessan.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: overflow detection not accurate when adding digits
Solution: Use a helper function
Use a helper function to better detect overflows before adding integer
digits to a long or an integer variable respectively. Signal the
overflow to the caller function.
closes: #13539
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: 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: [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
Signed-off-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.
Signed-off-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.
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: [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
Signed-off-by: Christian Brabandt <cb@256bit.org>
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
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Skipcol is not reset when topline changed scrolling cursor to top
Solution: reset skipcol
closes: #13528closes: #13532
Signed-off-by: Luuk van Baal <luukvbaal@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: wast filetype should be replaced by wat filetype
Solution: start using the official wat filetype name
runtime: rename `wast` filetype to `wat` (Wasm text format)
The problem is the name of the current filetype wast. When the plugin
was initially created, the file extension for Wasm text format was not
fixed and .wast was more popular.
However, recently .wat became the official file extension for
WebAssembly text (WAT) format and .wast is now a file extension for the
unofficial WAST format, which is a superset of .wat for the convenience
to describe the Wasm specification conformance tests.
https://webassembly.js.org/docs/contrib-wat-vs-wast.html
However for now, let's keep using the `wat` filetype even for the .wast
extension, so that we at least do not lose the filetype settings and
syntax highlighting. This can be adjusted later, if it turns out to have
a separate need for.
closes: #13533
Signed-off-by: rhysd <lin90162@yahoo.co.jp>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: recursive callback may cause issues on some archs
Solution: Decrease the limit drastically to 20
Recursive callback limit causes problems on some architectures
Since commit 47510f3d65 we have a test
that causes a recursive popup callback function to be executed. However
it seems the current limit of 'maxfuncdepth' option value is still too
recursive for some 32bit architectures (e.g. 32bit ARM).
So instead of allowing a default limit of 100 (default value for
'maxfuncdepth'), let's reduce this limit to 20. I don't think there is a
use case where one would need such a high recursive callback limit and a
limit of 20 seems reasonable (although it is currently hard-coded).
closes: #13495closes: #13502
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: matchparen highlight not cleared in completion mode
Solution: Clear matchparen highlighting in completion mode
Remove hard-coded hack in insexpand.c to clear the :3match before
displaying the completion menu.
Add a test for matchparen highlighting. While at it, move all test tests
related to the matchparen plugin into a separate test file.
closes: #13493closes: #13524
Signed-off-by: Christian Brabandt <cb@256bit.org>
// related #12589
// that should be the last chat (I) with Bram, r.i.p
Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: CI: test_termdebug may still fail
Solution: use term_wait() to make it more robust
closes: #13529
Signed-off-by: shane.xb.qian <shane.qian@foxmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: CI: test_termdebug fails
Solution: only test for a changed winlayout, if the window
width actually changed
Also, include an unrelated comment (which doesn't warrant its own patch
number)
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: No filetype support for xcompose files
Solution: Add filetype detection
closes: #13508
Signed-off-by: ObserverOfTime <chronobserver@disroot.org>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: statusline may look different than expected
Solution: do not check for highlighting of stl and stlnc characters
statusline fillchar may be different than expected
If the highlighting group for the statusline for the current window
|hl-StatusLine| or the non-current window |hl-StatusLineNC| are cleared
(or do not differ from each other), than Vim will use the hard-coded
fallback values '^' (for the non-current windows) or '=' (for the
current window). I believe this was done, to make sure the statusline
will always be visible and be distinguishable from the rest of the
window.
However, this may be unexpected, if a user explicitly defined those
fillchar characters just to notice that those values are then not used
by Vim.
So, let's assume users know what they are doing and just always return
the configured stl and stlnc values. And if they want the statusline to
be non-distinguishable from the rest of the window space, so be it. It
is their responsibility and Vim shall not know better what to use.
fixes: #13366closes: #13488
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: need more assignment tests
Solution: Add test for using different types in assignment, function
arguments and return values
closes: #13491
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Unsupported option causes rest of modeline test to be skipped.
Solution: Revert the change from patch 8.2.1432.
closes: #13499closes: #13500
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: Vim9: cannot convert list to string using +=
(after 9.0.2072)
Solution: convert dict index to string later in compile_member()
fixes: #13485closes: #13486
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: complete_info() skips entries with 'noselect'
Solution: Check, if first entry is at original text state
Unfortunately, Commit daef8c7437
introduced a regression, that when ':set completeopt+=noselect' is set
and no completion item has been selected yet, it did not fill the
complete_info['items'] list.
This happened, because the current match item did not have the
CP_ORIGINAL_TEXT flag set and then the cp->prev pointer did point to the
original flag item, which caused the following while loop to not being
run but being skipped instead.
So when the 'noselect' is set, only start with to the previous selection
item, if the initial completion item has the CP_ORIGINAL_TEXT flag set,
else use the 2nd previous item instead.
fixes: #13451closes: #13452
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: sound_playfile() fails when using powershell
Solution: quote filename using doublequotes, don't escape filename,
because it doesn't use the shell
Avoiding powershell escaping because mci open command doesn't support
single quoted filenames: open 'C:\whatever\sound.wav' is not valid.
closes: #13471
Signed-off-by: GuyBrush <miguel.barro@live.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
