From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alexander.turenko@tarantool.org>
Received: from smtp56.i.mail.ru (smtp56.i.mail.ru [217.69.128.36])
 (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 5D27E469719
 for <tarantool-patches@dev.tarantool.org>;
 Fri, 16 Oct 2020 01:46:42 +0300 (MSK)
Date: Fri, 16 Oct 2020 01:47:02 +0300
From: Alexander Turenko <alexander.turenko@tarantool.org>
Message-ID: <20201015224702.4ciwuhlvr2vfswj6@tkn_work_nb>
References: <cover.1602629628.git.tsafin@tarantool.org>
 <23f2b9468c529a6276ac75c1cfe81e60e1fabfb2.1602629628.git.tsafin@tarantool.org>
 <db10366a-44fc-d172-b6f3-9ab32228e7e9@tarantool.org>
 <055301d6a342$51ed3f00$f5c7bd00$@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <055301d6a342$51ed3f00$f5c7bd00$@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH 2.X v4 4/4] module api: box_ibuf_*
 wrappers
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: Timur Safin <tsafin@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org, 'Vladislav Shpilevoy' <v.shpilevoy@tarantool.org>

> : > +}
> : > +
> : > +void
> : > +box_ibuf_read_range(box_ibuf_t *ibuf, char ***rpos, char ***wpos)
> : > +{
> : > +	assert(ibuf != NULL);
> : > +	if (ibuf == NULL)
> : > +		return;
> : > +	if (rpos != NULL)
> : > +		*rpos = &ibuf->rpos;
> : > +	if (wpos != NULL)
> : > +		*wpos = &ibuf->wpos;
> : 
> : 3. I would better assume all the arguments are not NULL, and document
> : it. Especially ibuf itself. We need some border where to stop the
> : sanity checks, and this looks like an overkill already. For example,
> : box_tuple_ref() also works with a pointer, but it does not check for
> : it being not NULL. It is just stupid to call method of an object with
> : that object passed as NULL. The same below.
> 
> Please see updated branch tsafin/gh-5273-expand-module-api-v4 for the 
> current version. For rpos and wpos I need to check for NULL because 
> we may call for only single, particular argument (like we do in some 
> cases in current external module) thus we pass NULL there.

I think we should allow to pass NULL to the third parameters, but not to
the second ones. I don't see a reason to obtain 'wpos' using
_read_range() (it looks more natural to do so using _write_range()) and
to obtain just 'end' without left side of the buffer. To copy something
from right to left without the left border check? Maybe... However it
does not look how the for 'ibuf', where both pointers are moving forward
(it is defined by the _reserve() semantic).