From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp41.i.mail.ru (smtp41.i.mail.ru [94.100.177.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id ECED1469719 for ; Wed, 14 Oct 2020 06:30:57 +0300 (MSK) Date: Wed, 14 Oct 2020 06:31:17 +0300 From: Alexander Turenko Message-ID: <20201014033117.ipfnfm4bxfklhp4c@tkn_work_nb> References: <23f2b9468c529a6276ac75c1cfe81e60e1fabfb2.1602629628.git.tsafin@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <23f2b9468c529a6276ac75c1cfe81e60e1fabfb2.1602629628.git.tsafin@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 2.X v4 4/4] module api: box_ibuf_* wrappers List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Timur Safin Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org > +void > +box_ibuf_read_range(box_ibuf_t *ibuf, char ***rpos, char ***wpos) > +{ > + assert(ibuf != NULL); > + if (ibuf == NULL) > + return; So it'll not (at least stochastically) fail on ibuf pointer dereferencing on RelWithDebInfo, but will just silently ignore the usage error. I guess it is the bad pattern. At least I don't see anything similar in our code: we either assert() or fail with setting an error to the diagnostics area and returning of -1 / NULL or kinda. So I propose to jeave assert(), but remove the if (ibuf == NULL) {<...>}. Don't forget to update box_ibuf_write_range() in sync (not it has no assert()).