From: j DOT aldrich6 AT genie DOT com
Message-Id: <199605260317.AA134700656@relay1.geis.com>
Date: Sun, 26 May 96 03:20:00 UTC 0000
To: djgpp AT delorie DOT com
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Subject: Re: Trapping failed malloc cal

Reply to message 6357359    from MALCOLM AT MANAW on 05/24/96  9:49PM


>I seem to have been a little imprecise here. I know that you can check
>for NULL return from malloc, and I know about the new handler. I was
>wondering about more non-standard methods (or standard practices) to
>get the above result. Basicly I coded assuming I had enough memory,
>this is almost always true in dos (unless I have a memory leak), but
>under Windows and OS/2 the amount of memory given to the program is
>often too small, in these cases I would like my already written code
>to be able to exit a little more gracefully.

That IS the only way to check for running out of memory, unless you want
to hack malloc()'s internal structures.  Just check for NULL, and exit if you
see it.  More complex solutions could involve calling a trap function which,
by examining calls to malloc() with lesser amounts of memory, figures out
how much memory you actually need, but that is pretty extreme, especially
with virtual memory.  Besides, due to the way malloc() functions, there
could be a bunch of small blocks of free memory floating around that
together make up a substantial amount, but individually aren't enough
for anything.

The short answer is, even in real mode the only absolutely reliable way to
detect running out of memory is to trap on malloc().  That's it.  El fin.
Kaput.

John