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

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

- Raw text -