delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1996/05/25/23:43:05

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019