On Saturday, February 2, 2002, at 01:07 , Andreas Raab wrote:

>
> Not quite. The keyword of this discussion is "lazy" not virtual. I don't
> exactly care where the memory is (that's exactly what the manager is
> for). But I _do_ care that if I call malloc() and get a non-null pointer
> back then I should in fact be able to use that memory block. According
> to the explanations I've heard here that is _not_ the case. In other
> words the "lazy" malloc()ator may give me a pointer from malloc() but at
> the point where I actually start writing to that memory it may say
> "Oops. Sorry. I promised you that memory but I lied. I don't actually
> have any. You loose. Core dumped."

Sort of like a DNU...   "Oops, you gave me an object, but it doesn't 
actually understand the message.  I want a guarantee that the message 
will be understood."   The answer to that is very similar to the VM 
answer:  (a) this works better in most real-world scenarios, (b) the 
failures you are afraid of are quite rare and (c) if you are really 
*that* concerned, there are ways of avoiding the problem.

99% of Unix programs will core-dump just as hard if malloc() returns 
NULL, so what this does is (a) fail later and (b) allow some programs to 
run that would otherwise not run and (c) allow things to be simplified 
significantly.  Of course, you can wrap every malloc() with a check for 
a NULL return, but the plain fact is that a NULL-return from malloc() on 
a Unix system usually means you are hosed anyway, so there isn't really 
any point in handling it.  Just core-dump and be done with it.

Marcel