:> fail, generally speaking.
:
:Is this really the case? I'm pretty sure I've _never_ ignored the
:possibility of a NULL return from malloc, and I've been using it
:for nearly 20 years. I usually print a message and exit, but I
:never ignore it. I thought that was pretty standard practise.
:
:This is just a random comment, orthogonal to the overcommit issue,
:but I've seen both you and Matthew say this now, and I was surprised
:both times.
:
:--
:Andrew
The are dozens of libc routines which call malloc internally and return
allocated storage. strdup(), opendir(), fopen(), setvbuf(), asprintf(),
and so forth. Dozens. And while we might check some of these for NULL,
we don't check them all, and the ones we do check we tend to conclude
a failure other then a memory failure. We would assume that the directory
or file does not exist, for example. How many programmers check errno
after such a failure? Very few. How many programmers bother to even
*clear* errno before making these calls (since some system calls do not
set errno if it already non-zero). Virtually nobody.
Having malloc() return NULL due to some *unrelated* process running the
system out of swap is unnacceptable as it would result in serious
instability to a great many programs that were never designed to deal
with the case. Rather then crying about the system killing your favorite
process, you would be crying about half a dozen processes that are still
running no longer being stable. As a sysop, I would reboot a system
in such a state instantly.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
