X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
NNTP-Posting-Date: Wed, 22 Oct 2008 23:49:06 -0500
From: "Charles Sandmann" <cwsdpmi AT earthlink DOT net>
Newsgroups: comp.os.msdos.djgpp
References: <gcbnih$6pq$1 AT aioe DOT org> <MOadnT7eV5OCQHfVnZ2dnUVZ_g6dnZ2d AT earthlink DOT com> <gcf1pk$6q8$1 AT aioe DOT org> <EfSdnbKNq9VBs3HVnZ2dnUVZ_jidnZ2d AT earthlink DOT com> <gclvag$mho$1 AT aioe DOT org> <gdes8d$aqo$1 AT aioe DOT org> <t7Wdna5FmpsFEGPVnZ2dnUVZ_oPinZ2d AT earthlink DOT com> <gdmej0$ije$1 AT aioe DOT org> <gdn52v$3h7$1 AT aioe DOT org>
Subject: Re: failure of __dpmi_set_segment_limit() problem
Date: Wed, 22 Oct 2008 23:49:03 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-RFC2646: Format=Flowed; Original
Message-ID: <65Gdnb1mKbnfn53UnZ2dnUVZ_qPinZ2d@earthlink.com>
Lines: 40
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 64.91.192.48
X-Trace: sv3-36FLdw690+M7FGa0ed3eZn+pPtm9F7j3hGPBTodyIHbjHIR6QFw7EzJpxBy5nhTJXEhBFMNlMgyCKXt!WEm1zYmQfUaazp8BAwRa69OHkdkh6/93AW9S6p2Hha1LaB8saWnNENqe5WhaH9/MLMiqOtS28jbt!l8L1Ft0Go+xQ1pj+Z1LI40HjggrRfXU=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.39
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

>> 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.