Control: retitle -1 vim-tiny: Incorrect size reported when invoked as vi on 32-bit architectures Control: tag -1 + upstream confirmed
On Sat, Feb 15, 2020 at 12:28:24PM -0500, Tresi Arvizo wrote: > When invoked as vi, vim.tiny incorrectly reports the file size being > edited, reporting "898964 characters" no matter now large or small the > file is (tried files from 0 bytes to 71 MB). It works correctly when > invoked as vim.tiny. This seems to be a problem on the armhf/armv7l > architecture; I did not see it on an i686 machine. I've confirmed that it happens on other 32-bit architectures (e.g., mipsel) as well. > tresi@raspberrypi:~$ vi foo > hi > ~ > "foo" 1 line, 898964 characters > > tresi@raspberrypi:~$ vim.tiny foo > hi > ~ > "foo" 1L, 3C The difference here is that vi sources /etc/vim/vimrc.tiny and runs "set compatible". That changes the 'shortmess' option to not contain the "l" setting, so the translated strings are reported rather than the abbreviated L/C versions. Running "vim.tiny -u NONE foo" will show the same problem. Both versions should be going through the same code path, so I'm not sure yet why there's a difference. In this particular code path, it's trying to format the value of off_t (a 64-bit type) and, due to FEAT_NUM64 being disabled in vim-tiny, accesses it with “va_arg(ap, long int)” rather than “va_arg(ap, long long int)”. Re-compiling with FEAT_NUM64 defined causes it to work in both situations, but it's still quite odd that the L/C path works fine. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
