Warner Losh once stated:
=: Then, one can write a safe malloc, which will install the signal
=: handler, and touch every page in the the memory referenced by the
=: to-be-returned pointer. If the signal handler is invoked in the
=: progress, the to-be-returned memory must be returned back to the
=: system and NULL should be returned to the caller.
=This won't work all the time. FreeBSD overcommits swap space and you
=may get a SIGKILL even if you've touched all the pages. FreeBSD kills
=processes when swap space runs out.
That's my point! I advocate the use of some _other_ signal. Something
catchable.
=: However, my (in)ability to propose anything remotely sensible does
=: not change the facts established in this painful thread. That our
=: malloc does not conform to standards (for whatever reasons), and that
=: something should be done about it. That "something" must start with
=: documenting the flaw...
=The behavior is documented:
= The malloc() and calloc() functions return a pointer to the allocated
= memory if successful; otherwise a NULL pointer is returned.
=
=What the system does when it has resource shortages is beyond the scope
=of the ANSI-C standard, so I don't see why you say that FreeBSD's
=malloc isn't standard conforming.
In case of "resource shortage" the malloc should be unsuccessful
and return NULL. Instead, right now you may still get a non-NULL
pointer, but get a SIGKILL when you try to use the rightfully
allocated memory.
-mi
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
