<div dir="ltr">What are other practical use cases where malloc returns NULL.<div><br></div><div>You mentioned programmer error.</div><div>I second, and mention restricted environment where admin ulimits your virtual memory.</div><div><br></div><div>I'll be happy to hear more.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 17, 2015 at 9:51 PM, Oleg Goldshmidt <span dir="ltr"><<a href="mailto:pub@goldshmidt.org" target="_blank">pub@goldshmidt.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Elazar Leibovich <<a href="mailto:elazarl@gmail.com">elazarl@gmail.com</a>> writes:<br>
<br>
> Regarding 5-6. What I'm saying is, seeing malloc returning NULL in<br>
> production is very rare.<br>
<br>
</span>Hope dies last.. ;-)<br>
<span class=""><br>
> I personally never seen that.<br>
<br>
</span>So you've been lucky so far. At some point you will inevitably run into<br>
client code that occasionally does something stupid like passing a<br>
signed integer as size. Trust me, when that happens the size parameter<br>
usually turns out to be -6. You will have no control over it.<br>
<span class=""><br>
> I think that the OOM killer would wreck havoc to the system before it<br>
> would happen,<br>
<br>
</span>Why do you assume that? How *can* you assume that given that OOM<br>
policies can be configured (at runtime)?<br>
<br>
Apart from everything else, why do you assume that malloc only fails<br>
when there is not enough memory?<br>
<br>
And if you allow - nay, require! - that the user specifies a custom<br>
allocator, how do you know *that* won't fail for some weird (or<br>
perfectly logical, as the case may be) reason?<br>
<span class=""><br>
> hence, crashing when malloc returns NULL is a reasonable behavior.<br>
<br>
</span>For a non-critical single process application under very special<br>
circumstances - maybe. What if the crash happens while client code is<br>
tweaking some shared memory, holding a lock or some other resource<br>
(where a crash would leave some data your library does not control in an<br>
inconsistent state that will cause problems for other processes or after<br>
restart), or in general needs to do some cleanup / bookkeeping / logging<br>
(to tell the user what happened) before dying - how can you possibly<br>
call hard crash "reasonable behaviour"?<br>
<span class=""><br>
> Regarding 7, this does not complicate the allocation API, it<br>
> complicates my API, since I'll have functions that cannot fail,<br>
> generally speaking, but allocates memory.<br>
<br>
</span>This implies that you need to handle allocation (and all other) errors<br>
inside such functions to provide the "no exceptions" guarantee. Your<br>
options, in order of increased sophistication (you can actually do this<br>
in stages and hope to get feedback rather than being ignored):<br>
<br>
1. Decide how and do that - that's a policy. See if this is attractve to<br>
   your users. Hope to get emails saying "I wish you didn't abort."<br>
<br>
   [If you get such emails feel very proud - someone cares enough, you<br>
   probably did a very good job on everything else.]<br>
<br>
2. Provide several different policies and a configuration mechanism to<br>
   choose - see if this is more successful than #1 above. Hope to get<br>
   emails saying "I wish you would add this other policy."<br>
<br>
3. Provide a callback hook so that a user can implement and register a<br>
   handler - effectively, support custom policies.<br>
<br>
   By the time you get to this stage you may realize that you may just<br>
   as well return a status code and let the user handle the<br>
   condition. I expect this to be easier for users than registering<br>
   callbacks. It will also be more flexible since different policies may<br>
   be applied in different places in a single client program.<br>
<span class=""><br>
> Those would have to return error, and the user would have to check the<br>
> error.<br>
<br>
</span>As both Guy and I said before, this is the proper behaviour for a<br>
general purpose library.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Oleg Goldshmidt | <a href="mailto:pub@goldshmidt.org">pub@goldshmidt.org</a><br>
</font></span></blockquote></div><br></div>