[Ecls-list] Patch: remove sbrk() usage in handle_signal()

[Josh Elsasser]

On Sat, Oct 04, 2008 at 09:13:08PM -0400, Geo Carncross wrote:
> On Sat, Oct 4, 2008 at 3:16 PM, Josh Elsasser <josh at elsasser.org> wrote:
> > The new stack overflow detection code uses sbrk(), which is not
> > portable.
> 
> Do you have a system that ECL runs on that doesn't have sbrk()?
> 
> >  I'm guessing that it was used to detect if the signal
> > handler was executing on the alternate signal stack, if that is the
> > case then sigaltstack() would be the portable way to test for that.
> 
> It isn't. The sbrk(0) is the top of the heap. The only things above it
> should be mmap'd regions, and the stack. Since most unixes
> automatically extend the stack, the first SIGSEGV above it is either a
> very errant pointer, or the stack guard.

brk() and sbrk() are not standard interfaces, their behavior is system
dependant.  On my system (OpenBSD/i386) they adjust the size of the
process's data segment, which is located in a different address range
than memory allocated by malloc().  With the current address space
layout, sbrk(0) will always return an address less than any stack or
heap address.

I could be wrong, but I don't see any reason why the stack would have
to be located above the heap either.

> I believe Bohem GC requires sbrk() so I didn't think I was introducing
> any new dependencies, either.

It appears to use sbrk() on some systems, yes.