[CrackMonkey] I love the Innurnet. It runs on such silly hardware.

[Nick Moffitt]

	Yeah, the 390 will take over the world with its 31-bit
pointers.

----- Forwarded message from Ralf Schandl <Ralf.Schandl at t-online.de> -----


Hello,

today (ehm yesterday) I found a little bug in Vim 60ac on OS/390 Unix.

Assume you have a file containing the line

Vim rules

Now place the cursor on the 'r' anf do ^V$y and you end up with
something like:

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;
   for(;;)
   {

       if(ptr_to_start_col >= endptr) break;
   }

This failed, because before the for-loop endptr was always
(ptr_to_start_col-1).

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.

Ralf

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.


--
Ralf Schandl                    @home: ralf.schandl at t-online.de
                                @work: schandl at de.ibm.com

[patch snipped]

----- End forwarded message -----

-- 
You are not entitled to your opinions.
 
	01234567 <- The amazing* indent-o-meter! 
        ^	    (*: Indent-o-meter may not actually amaze.)