Mail Archives: djgpp/2008/10/22/08:15:30
"Rod Pemberton" <do_not_have AT nohavenot DOT cmm> wrote in message
news:gdmej0$ije$1 AT aioe DOT org...
> "Charles Sandmann" <cwsdpmi AT earthlink DOT net> wrote in message
> news:t7Wdna5FmpsFEGPVnZ2dnUVZ_oPinZ2d AT earthlink DOT com...
> > You are not flagging to sbrk() that you have changed the segment limit;
so
> > when you call anything which calls sbrk() that requires it resize the
> memory
> > it resets the limit. Don't set the limit to -1 manually, call
> > _djgpp_nearptr_enable instead or look at it's source to see which flags
> need
> > setting. There are some old FAQ and usenet articles about this if you
> > search long enough..., but the easy thing is to call the libc function.
> >
>
> Thanks. Maybe it's just me, but I'd consider that to be bug in sbrk()...
> the limit is already maxed. Yes, this program doesn't specifically need
> that method and could use _djgpp_nearptr_enable.
So, using __djgpp_nearptr_enable() should fix it then? Yes for ds. But,
the call fails to set cs.
The call does fix ds, but then it fails to set cs. Normally, both limits
for cs and ds are set to 0xFFFFFFFF (or -1) by __djgpp_nearptr_enable().
However, with this problem code, cs doesn't get set to -1 by
__djgpp_nearptr_enable() or it's being reset... The call does fix ds
though, as does enabling _CRT0_FLAG_NEARPTR in _crt0_startup_flags or
setting ___djgpp_selector_limit to -1 in assembly.
I think something more is going on here. Setting some DOS var's shouldn't
have any affect, but does. v2.04 is consistent, while v2.03 isn't. In my
mind, the selectors are being corrupted or reset or there is a memory
allocation error due to a boundary condition or calculation, etc.
Rod Pemberton
- Raw text -