aboutsummaryrefslogtreecommitdiff
path: root/scripts/cdoc_parser.lua
diff options
context:
space:
mode:
authorzeertzjq <zeertzjq@outlook.com>2024-12-10 13:24:54 +0800
committerzeertzjq <zeertzjq@outlook.com>2024-12-10 14:29:24 +0800
commit2336389d236f3d80575a5139e92c551c005b0eff (patch)
tree0979fe1164b1e13625384a11b03590ca365d6849 /scripts/cdoc_parser.lua
parent4889935a7a0e188d6fb247cbc3b3bb0c5b0ed731 (diff)
downloadrneovim-2336389d236f3d80575a5139e92c551c005b0eff.tar.gz
rneovim-2336389d236f3d80575a5139e92c551c005b0eff.tar.bz2
rneovim-2336389d236f3d80575a5139e92c551c005b0eff.zip
vim-patch:9.0.2112: [security]: overflow in shift_line
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: vim/vim#13535 https://github.com/vim/vim/commit/6bf131888a3d1de62bbfa8a7ea03c0ddccfd496e Skip the test for now, as it takes too long and requires other fixes. Co-authored-by: Christian Brabandt <cb@256bit.org>
Diffstat (limited to 'scripts/cdoc_parser.lua')
0 files changed, 0 insertions, 0 deletions