[vim/vim] Test_very_large_count fails on 32bit systems (Issue #9072)

Ondřej Súkup

unread,

Oct 31, 2021, 9:26:00 AM10/31/21

to vim/vim, Subscribed

Steps to reproduce

run vim testsuite on i586

Expected behaviour

test pass

Operating system

openSUSE, Tumbleweed,

Version of Vim

8.2.3567

Logs and stack traces

1095s] Found errors in Test_very_large_count():
[ 1095s] command line..script /home/abuild/rpmbuild/BUILD/vim-8.2.3567/src/testdir/runtest.vim[450]..function RunTheTest[44]..Test_very_large_count line 6: command did not fail: norm 44444444444444p

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub.
Triage notifications on the go with GitHub Mobile for iOS or Android.

Tony Mechelynck

unread,

Oct 31, 2021, 10:38:28 AM10/31/21

to vim/vim, Subscribed

I thought current openSUSE operating systems were published for 64-bit processors only? Or are you compiling and running 32-bit Vim on a 64-bit OS? (It is possible on openSUSE, but only if the appropriate -32bit packages are installed.)

James McCoy

unread,

Oct 31, 2021, 10:44:22 AM10/31/21

to vim/vim, Subscribed

This is also an issue on Debian. There are multiple 32-bit architectures where Linux is still used.

Bram Moolenaar

unread,

Nov 1, 2021, 6:59:30 PM11/1/21

to vim/vim, Subscribed

Closed #9072 via ec6e630.

Bram Moolenaar

unread,

Nov 1, 2021, 7:14:31 PM11/1/21

to vim/vim, Subscribed

Please check that the issue is actually fixed. Perhaps we should also add v:intsize so we can fix the FIXME. Although the most interesting is that sizeof(long) != sizeof(char *). What would we call that, v:longnopointer?

James McCoy

unread,

Nov 2, 2021, 7:14:25 AM11/2/21

to vim/vim, Subscribed

This doesn't fix the test. On i386 Linux builds, v:numbersize is still 64 because varnumber_T is int64_t. Also, sizeof(long) is always the same as the size of a pointer type on Linux. As mentioned in the test comment, the fix the test is trying to check doesn't work when sizeof(int) == sizeof(long), which is the case on 32-bit Linux.

Bram Moolenaar

unread,

Nov 2, 2021, 10:01:19 AM11/2/21

to vim...@googlegroups.com, James McCoy

James McCoy wrote:

> This doesn't fix the test. On i386 Linux builds, `v:numbersize` is

> still 64 because `varnumber_T` is `int64_t`. Also, `sizeof(long)` is

> always the same as the size of a pointer type on Linux. As mentioned
> in the test comment, the fix the test is trying to check doesn't work

> when `sizeof(int) == sizeof(long)`, which is the case on 32-bit Linux.

OK, so in this case sizeof(int) matters, and I don't think there is a
simple way to know that in a script. I think we'll add:
v:sizeofint
v:sizeoflong
v:sizeofpointer

Then we can check what we actually require.

--
Life would be so much easier if we could just look at the source code.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Ondřej Súkup

unread,

Nov 2, 2021, 10:27:46 AM11/2/21

to vim/vim, Subscribed

@tonymec openSUSE:Tumbleweed still ships i586 flavor

@brammool same error as before

Ondřej Súkup

unread,

Nov 2, 2021, 10:37:50 AM11/2/21

to vim/vim, Subscribed

ahh , and also looks like this test is problematic on BigEndian systems like s390x

Bram Moolenaar

unread,

Nov 2, 2021, 7:36:27 PM11/2/21

to vim/vim, Subscribed

I thought using a float would work, but the test still fails on MS-Windows. Not sure why, the float multiplication cannot overflow and comparing with the int value should be false.

One alternative is to use an unsigned long. Not sure if we always catch the overflow then.
Any other ideas?

Reply all

Reply to author

Forward