From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kostja.osipov@gmail.com>
Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com
 [209.85.167.67])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id DAF8546970E
 for <tarantool-patches@dev.tarantool.org>;
 Wed,  5 Feb 2020 12:49:48 +0300 (MSK)
Received: by mail-lf1-f67.google.com with SMTP id y19so1007099lfl.9
 for <tarantool-patches@dev.tarantool.org>;
 Wed, 05 Feb 2020 01:49:48 -0800 (PST)
Date: Wed, 5 Feb 2020 12:49:46 +0300
From: Konstantin Osipov <kostja.osipov@gmail.com>
Message-ID: <20200205094945.GB4624@atlas>
References: <20200128192249.10023-1-gorcunov@gmail.com>
 <20200128192249.10023-3-gorcunov@gmail.com>
 <20200203143928.GG547@tarantool.org> <20200204221556.GE20146@atlas>
 <20200205074655.GH12445@uranus>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200205074655.GH12445@uranus>
Subject: Re: [Tarantool-patches] [PATCH v7 2/5] box/applier: add missing
 diag_set on region_alloc failure
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: tml <tarantool-patches@dev.tarantool.org>

* Cyrill Gorcunov <gorcunov@gmail.com> [20/02/05 10:50]:
> > This code is dead actually. There is no region quota and OOM is
> > impossible here. We haven't had a policy to check these errors
> > before. 
> > 
> > No harm in pushing it, but no value either.
> 
> Wait, region_alloc (as other slab related functions) are using
> malloc call on low level (see slab_get_large) thus there is
> no guarantee that NULL won't be ever returned, moreover malloc
> interface never claimed that NULL will be returned iif there
> no free memory in the system (actually this is not how malloc
> works now but api points explicitly that we should be ready
> for NULL and handle it properly).
> 
> IOW I think we should handle NULLs to be stable in long terms.

While I sort of agree with the discipline of checking the malloc
return value, just as a style habit, you won't get NULL
from malloc() in practice. OOM killer will do its job first. 

Also if you do, you're just as good crashing next line, when
accessing null pointer. 

-- 
Konstantin Osipov, Moscow, Russia
https://scylladb.com