Date: Fri, 6 Mar 92 11:35 +1000
From: Bill Metzenthen <APM233M AT vaxc DOT cc DOT monash DOT edu DOT au>
To: djgpp AT sun DOT soe DOT clarkson DOT edu, dj AT ctron DOT com
Status: O


In a posting to this group I suggested that the computation of pn_lo_last
in valloc.c (v1.05) be changed to:

   pn_lo_last = ((r.r_ax+lol) >> 8) -1; /* highest real mem 4K block (WM) */

This was to remove a bug.

In version 1.06 alpha of DJGPP, different code is used:

   pn_lo_last = ((r.r_ax+lol-0xFF)>>8);	/* highest real mem 4K block */

This is obviously not exactly equivalent to my suggestion. The problem is
that it does not remove the bug.

To demonstrate this, consider the following example:
Suppose that DOS returns lol=255 (i.e. there are 255 paragraphs of memory
free), and r.r_ax=0x8000 (i.e. DOS grants the 255 paragraphs starting at
address 0x80000). 255 paragraphs is just less than one 4k page of memory.
The computation of pn_lo_first in valloc.c will give  pn_lo_first=0x80  and
since there is no 4k page available, we want the computation of pn_lo_last
to give  pn_lo_last=0x7f  (or smaller). If the computation returns
pn_lo_last=0x80  then go32 will use one 4k page starting at address
0x80000, probably subsequently causing whatever happens to be in the
paragraph starting at address 0x800ff to be corrupted.
So, let's try the two methods:
(a) my suggestion
   ((r.r_ax+lol) >> 8) -1 = ((0x8000+0xff) >> 8) -1 = 0x7f
(b) 1.06 alpha method
   ((r.r_ax+lol-0xFF)>>8) = ((0x8000+0xff-0xff)>>8) = 0x80

Actually, I find my suggestion easier to understand than the approach
used in 1.06 alpha, but if one's taste favours the latter approach then
it should be changed to:

   pn_lo_last = ((r.r_ax+lol-0x100)>>8); /* highest real mem 4K block (WM) */



Bill Metzenthen
apm233m AT vaxc DOT cc DOT monash DOT edu DOT au