The size of long varies depending on architecture, in contrast to the
MAXLNUM constant which sets the maximum allowable number of lines to
2^32-1. This discrepancy may lead to hard to detect bugs, for example
https://github.com/neovim/neovim/issues/18454. Setting linenr_T to a
fix maximum size of 2^32-1 will prevent this type of errors in the
future.
Also change the variables `amount` and `amount_after` to be linenr_T
since they're referring to "the line number difference" between two
texts.
Problem: MS-Windows: running out of memory for a very long line.
Solution: Use a 32 bit value for MAXCOL also when ints are 64 bits.
8e38555ece
This still fails Vim's Windows CI, so let's see what happens...
* refactor: format all C files under nvim
* refactor: disable formatting for Vim-owned files:
* src/nvim/indent_c.c
* src/nvim/regexp.c
* src/nvim/regexp_nfa.c
* src/nvim/testdir/samples/memfile_test.c
Should actually be silencing that for the sake of the case when `long` is
actually not 64-bit. But it appears that Vim had already defined maximal line
number. And even declared that exact value invalid, so no need in silencing.
Move files from src/ to src/nvim/.
- src/nvim/ becomes the new root dir for nvim executable sources.
- src/libnvim/ is planned to become root dir of the neovim library.
