From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (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 9FE284696C3 for ; Fri, 10 Apr 2020 10:16:29 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id r7so1014342ljg.13 for ; Fri, 10 Apr 2020 00:16:29 -0700 (PDT) Date: Fri, 10 Apr 2020 10:16:27 +0300 From: Cyrill Gorcunov Message-ID: <20200410071627.GF3072@uranus> References: <0bd904ddc2f18b1a078aac62fcc95485b36edd92.1586486220.git.alexander.turenko@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0bd904ddc2f18b1a078aac62fcc95485b36edd92.1586486220.git.alexander.turenko@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 01/13] popen: require popen handle to be non-NULL List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Turenko Cc: tarantool-patches@dev.tarantool.org On Fri, Apr 10, 2020 at 05:50:39AM +0300, Alexander Turenko wrote: > Further commits will add proper entries into the diagnostics area for > failures inside popen functions. We should either report handle == NULL > case via the diagnostics area or ensure that the NULL handle case is not > possible. > > The latter approach is implemented in this commit. There are two > reasons for this: > > * This way simplifies function contracts (one less kind of failure). > * The popen Lua module (that will be implemented in the further commits) > will not construct any logic using NULL as a handle. When 'NULL > handle' error is not possible in the C API, it will be easier to > verify that this failure is not possible the Lua API. > > A user of the C API should take care to don't call those functions with > NULL handle. > > Part of #4031 Acked-by: Cyrill Gorcunov