From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp58.i.mail.ru (smtp58.i.mail.ru [217.69.128.38]) (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 95E4E469719 for ; Mon, 5 Oct 2020 10:26:17 +0300 (MSK) Date: Mon, 5 Oct 2020 10:26:32 +0300 From: Alexander Turenko Message-ID: <20201005072632.t3mistqup5uwjzn6@tkn_work_nb> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH 00/14] RFC: module api: extend for external key_def Lua module List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy Cc: tarantool-patches@dev.tarantool.org > What also worries me: I found that actual behaviour of luaT_tuple_new() > is different from what I expected in the past: it may raise an error > when serialization fails. I didn't expect this, so I'll look how much it > may affect key_def and merger modules (built-in and external ones). For > now I just described the actual contract in the API comments for > luaT_tuple_new() and luaT_tuple_encode(). I looked at usages of the function and found leaks and inconsistences caused by raising a Lua error from luaT_tuple_new(). Filed issue: https://github.com/tarantool/tarantool/issues/5382 So it should be resolved before exposing the function to the module API. I'll do. WBR, Alexander Turenko.