Date: Tue, 3 Jul 2001 15:12:29 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: djgpp-workers AT delorie DOT com
cc: Charles Sandmann <sandmann AT clio DOT rice DOT edu>
Subject: Re: malloc() problem, DJDEV 203
In-Reply-To: <200107022219.SAA04299@envy.delorie.com>
Message-ID: <Pine.SUN.3.91.1010703150917.19306L-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


On Mon, 2 Jul 2001, DJ Delorie wrote:

> 
> > I noticed this whilst checking a test I have written for my own
> > malloc() wrapper function.  malloc() does not indicate failure for a
> > very large allocation.
> 
> Try -8 instead of -1, although size_t is unsigned, so you really
> should use 4294967288U, not -8.  Your request is (humorously) getting
> rounded up (to a 8-byte boundary) from 4294967295U (-1) to 4294967296U
> (0), and 0 is a valid request to malloc.
> 
> It would be trivial to add a check for values 4294967289U through
> 4294967295U in djgpp's src/libc/ansi/stdlib/malloc.c if someone wants
> to use this as an excuse to get into djgpp development ;-)

How about if we fail any allocation that's larger than what 
__dpmi_get_free_memory_information returns in the first member of the 
struct it returns?  Or are there DPMI hosts that lie about that?

If that doesn't work, I think we can safely decline anything above 2GB, 
which will avoid the signed/unsigned nuisance (inside malloc as well).