[developers] PET 0.99.7 Patches

[Stephan Oepen]

hi eric,

well done on solving that flop(1) mystery (and nice work on improving
the configure scripts too)!  in retrospect, i believe the behavior we
saw (silly messages about type incompatibilities while expanding) can
all be interpreted as memory corruption, although it remains somewhat
mysterious how exactly we get to that point: once mmap(2)ed, at some
location and for a specific size, those chunks cannot be overwritten 
by the kernel, i.e. due to loading of shared libraries, i think.  it
is just possible, of course, that flop(1) has a buffer overflow error
somewhere in it still ...  a memory debugger might be required here.

anyway, i thought i could propose a further simplification of what you 
did: we actually saw this problem on newer 2.4 kernels too (e.g. RHEL
2.4.21-27.0.2).  hence, it would seem feasible to always use the more
conservative:

  #define _CORE_HIGH 0xbf429fff

just now, when writing this, i also saw your additional diff(1):

  #define _MMAP_DOWN

this is something i have had in my version of `chunk-alloc.cpp' for a
while now, mostly running on 2.4 kernels.  i would have to refresh my
understanding of what exactly the flag does, but i suspect it is safe
to use generally on modern Linuces too.

bernd or ulrich, would you agree to the above?

                                                all the best  -  oe

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ Universitetet i Oslo (ILN); Boks 1102 Blindern; 0317 Oslo; (+47) 2285 7989
+++     CSLI Stanford; Ventura Hall; Stanford, CA 94305; (+1 650) 723 0515
+++       --- oe at csli.stanford.edu; oe at hf.uio.no; stephan at oepen.net ---
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++