Serg,

> memStart would be negative.

I've often worried about this.  When I did the initial port of Squeak to SunOS I
suspected one problem of being caused by malloc returning a "negative" address (it
turned out to be something entirely different).  I had similar worries about the
DEC Alpha port, where Squeak "only just" manages to scrape by as a 32-bit
application living ("squatting"? ;) in a 64-bit universe -- but using the relevant
flags to the linker seems to ensure the correct behaviour.

Andreas suggests ensuring that the compiler treats ints as unsigned.  If you can do
this then it'll work (gcc, for example, has -funsigned-char but I don't think it
has -funsigned-int).  However, there are literally hundreds of places in the
interpreter where addresses are implicitly assumed to be non-negative 32-bit signed
values, and I'd be terrified of trying to convince myself that the interpreter were
100% correct with any smple "workaround".  Even #defining int to be unsigned int
would leave me scared, since there's no way to know what secondary effects this
might have on stuff imported from header files (even if the #define was always done
after the last header file were included -- since #defines are felt inside other
#defines at expansion time, not definition time).

My suggestion would be to avoid malloc entirely and to allocate an area of memory
by some other means, in a way that leaves you certain that it can only ever be in
the lower half of the address space.  One possibility would be to mmap() the object
memory from /dev/zero, at an address that you know to be safe -- you would be able
to treat the memory so allocated pretty much like that allocated by malloc().
Another possibility might be to investigate if the BeOS linker has flags to control
where the uninitialised data segment is mapped for an application: if you can set
this manually, then you should be able to choose a suitable "safe" address.

If you run into real problems with this then let me know.  I have BeOS installed on
my Mac, so I could try to come up with a suitable workaround for you.

Sorry that I can't offer anything more positive and/or helpful and/or concrete... :(

Regards,

Ian