Mail Archives: djgpp-workers/2002/05/16/23:48:52
> > The DJGPP implementation of sbrk does accept a negative argument, but
> > it doesn't return that memory to the system.
>
> So, what does it do with that memory. Is it simply abandoned?
No, it's just sitting there, still allocated, waiting for you to ask
for it again with sbrk() with a positive value.
> What does it do if the argument is the negative of the total size
> allocated continuously so far?
It would set the selector limits to zero, the start of the allocation
space to zero, and you would die very badly (you would in effect be
making all the code, data and stack not available). In any case you
pass a negative number, you may be making stack/data required to run
be unavailable.
> What if the negative argument is
> larger magnitude that what has been allocated?
It either fails, or it would be treated as a huge positive value
(and fail when DPMI was unhappy returning 3.8Gb of memory in a single
block). Then you would probably get a return of -1.
> What happens on a subsequent call for a normal positive size?
If you haven't aborted something, it should just increase the "break"
point by the amount you added (to the last successful return).
> If these things can foul it up nmalloc should protect against
> generating such calls with oversized requests.
As a matter of fact, the current CVS malloc has some additional protections
against "fluffy" allocations over 2Gb in size in malloc to fix these
sorts of issues (and would need to be in the new version too).
> Maybe it could limit allocation requests to INT_MAX after rounding up.
Minus some fluff for roundup. It's in CVS malloc already.
Note, it is possible to use more than 2Gb of address space in a DJGPP
application if you use multiple sbrk() calls and beware signed/unsigned
problems. (I've tested CWSDPMI versions with more than 2Gb).
- Raw text -