Re: Vim halt bug
I don't get exactly what you do.
You go to some line and then start a visual block selection.
What are the keys you use.
PS: A problem found in 6.0ac comes to my mind (because I found it while
doing a visual selection). This was related to memory calculation. The
problem was that some zServers use 31 bit pointer arithmetics. The
error description is appended below.
Subject : Nice bug in Vim on OS390 Unix
today (ehm yesterday) I found a little bug in Vim 60ac on OS/390 Unix.
Assume you have a file containing the line
Now place the cursor on the 'r' anf do ^V$y and you end up with
Out of memory allocating 4294967289 bytes.
(BTW: 60z just crashed here)
I quickly found the location of the bug, but I didn't understand it.
After some time I had it:
If ou use '$' to jump to the end of a line Vim internally uses 0x7fffffff
as the cursor position, while calculating the correct amount of memory
needed for the yanked test. It counts from the start of the selection to
the cursor position or the end of line ('\0'). It has code like (not
exactly, just an example):
#define MAXCOL 0x7fffffff
endptr = ptr_to_start_col + MAXCOL;
if(ptr_to_start_col >= endptr) break;
This failed, because before the for-loop endptr was always
Well S/390 use _31_ bit pointer arithmetics, but Vim assumes 32 bits.
Solution: Reduce MAX_COL to 0x3FFFFFFF for OS/390 Unix. Just a small
patch for vim.h
The patch is attached.
PS: Newer generations of S/390 machines use 64 bit pointers, but I don't
know how to distinguish them. So I generally set MAXCOL to 0x3FFFFFFF.
For every problem there's a clear, obvious solution that's totally wrong.