Date: Tue, 24 Jun 1997 15:36:02 +0200 (MET DST)
From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Subject: Re: Debugging options
In-reply-to: <33AFC44E.6079@bo.dada.it>
To: Diego Zuccato <dz AT bo DOT dada DOT it>
Cc: djgpp-workers AT delorie DOT com
Message-id: <Pine.LNX.3.91.970624152718.10672C-100000@acp3bf>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
Precedence: bulk

> Yesterday night I thought : "why can't DJGPP use a different 'segment'
> for each malloc()/new to allow bounds checking ?".
> Since I never saw it implemented, I don't know if it could be possible.
> This way, if someone try to access memory never allocated, he gets a
> SIGSEGV. Same technique could be used to catch writing attempts to a
> NULL ptr.

Such techniques are available, but not on DJGPP. On Linux, there's the
ElectricFence that does almost what you suggest (although not exactly). It
can't really be done by use of lots of segments, because in a flat memory
model, memory access doesn't explicitly use segments at all (i.e. there is
no such thing as a 'far pointer' in DJGPP). 

But something similar is possible, and used by ElectricFence: you can make
a 'hole' (more technically: a page of unmapped memory) in address space
behind (or in front) of every malloc()ed block, so that if you write past
the bounds of an array or something similar, you'll get a page fault. This
can help, but it's not perfect. If you access further out of bounds, you
will sooner or later hit the next, existing page of memory behind the
hole. 

In DJGPP, this technique would be in danger of overflowing the space
used for the 'page tables', I suspect.

HBB