Mail Archives: djgpp/2008/10/23/01:01:55
>> 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.
sbrk() can be called thousands of times during program execution, so there
is incentive to avoid extra operations there unless absolutely needed. It
caches
the presumed limit for speed.
> 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...
cs limit is being reset - look at the crt0.S code carefully..
This appears to be a bug in sbrk() - or maybe a change in philosophy at
somepoint if CS really should also be big. But the section that sets CS
limits
is for some reason before the flag test. Since it seems to have been that
way
for 13 years now, not a huge problem.
> 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.
It's just sizing and alignment issues. Things like environment variables
are
copied to 32-bit memory; so may bump you over a 64K boundary which
bumps the sbrk() internal segment limit a notch. The size of the calls the
libc() makes. So it could be that one of the releases is consistently near
the
limit, while the other isn't.
- Raw text -