From: Alexander Turenko <alexander.turenko@tarantool.org> To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH 2.5/3] merger: clean fiber-local Lua stack after next() Date: Fri, 19 Jun 2020 10:41:22 +0300 [thread overview] Message-ID: <20200619074122.7ijjpgqkmqtdbxpq@tkn_work_nb> (raw) In-Reply-To: <87fd0e77-6964-b75a-3f44-d65741d69d76@tarantool.org> On Fri, Jun 19, 2020 at 12:48:23AM +0200, Vladislav Shpilevoy wrote: > Thanks for the fixes! > > On 17/06/2020 19:53, Alexander Turenko wrote: > > Thanks for the careful review! > > > >>> + if (top >= 0) > >>> + lua_settop(L, top); > >> > >> 1. lua_settop() works fine even when top is -1. It basically means > >> 'set top to the latest element' = 'leave the stack untouched'. I > >> checked the implementation, should work. > > > > I'm not sure we can lean on this. See, Lua 5.1 Reference Manual [1] states the > > following about lua_settop(): > > > > | Accepts any acceptable index, or 0, and sets the stack top to this index. > > > > And defines an acceptable index as follows: > > > > | More formally, we define an acceptable index as follows: > > | > > | (index < 0 && abs(index) <= top) || > > | (index > 0 && index <= stackspace) > > > > However LuaJIT has the following condition: > > You said a few lines above that we shouldn't rely on implementation > specifics, and yet you appeal to it here. I just show where Lua and LuaJIT allows more than the reference manual guarantees to be successful. > As I see, both the implementation, and the format definition of the > valid index mean that lua_settop(-1) is no op. Means the same as > lua_settop(lua_gettop()). Let `top` be zero (empty stack) and `index` be -1. (index < 0 && abs(index) <= top) condition fails. I don't see any mistake in this math. > > >>> +#include <lua.h> /* lua_*() */ > >>> +#include <lauxlib.h> /* struct luaL_Reg */ > >>> +#include "lib/core/diag.h" /* struct error, diag_*() */ > >>> +#include "fiber.h" /* fiber_self() */ > >>> +#include "lua/utils.h" /* luaL_checkcdata() */ > >>> +#include "box/merger.h" /* struct merge_source, > >>> + merge_source_next() */ > >> > >> 3. Do you really need these comments? Anyway they tend to outdate > >> fast, because no one watches these comments when changes the code, > >> uses some new functions from these files, etc. > > > > I actively use them during the initial development: when I remove some > > experimental code, I verify whether I should remove some header. > > > > There is nothing bad if it becomes a bit outdated: some of headers used > > more, some becomes unused. If one want to clean them up, those comments > > will give an idea how to obtain possibly unused headers using simple > > pattern matching. Then the list of possibly unused headers may be > > verified by removing them and try to compile. > > > > I find it convenient sometimes, so I would prefer to leave the comments > > (if you don't strongly disagree). > > I don't care about include comments much. I just warn you that > it is not in our code style (AFAIK, but I didn't check), and if > someone but you will change the merger code, the comments are likely > to outdate and turn into just confusing text not meaning anything. I asked teammates and several of them speak against it. So I'll remove them.
next prev parent reply other threads:[~2020-06-19 7:42 UTC|newest] Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-01 18:10 [Tarantool-patches] [PATCH 0/3] Merger's NULL defererence Alexander Turenko 2020-06-01 18:10 ` [Tarantool-patches] [PATCH 1/3] merger: drop luaL prefix where contract allows it Alexander Turenko 2020-06-02 22:47 ` Vladislav Shpilevoy 2020-06-07 16:57 ` Alexander Turenko 2020-06-11 16:17 ` Vladislav Shpilevoy 2020-06-16 11:59 ` Igor Munkin 2020-06-17 17:53 ` Alexander Turenko 2020-06-01 18:10 ` [Tarantool-patches] [PATCH 2/3] merger: fix NULL dereference when called via iproto Alexander Turenko 2020-06-02 22:48 ` Vladislav Shpilevoy 2020-06-07 16:58 ` Alexander Turenko 2020-06-11 16:18 ` Vladislav Shpilevoy 2020-06-17 17:53 ` Alexander Turenko 2020-06-18 22:47 ` Vladislav Shpilevoy 2020-06-01 18:10 ` [Tarantool-patches] [PATCH 3/3] lua: expose temporary Lua state for iproto calls Alexander Turenko 2020-06-02 22:48 ` Vladislav Shpilevoy 2020-06-07 16:58 ` Alexander Turenko 2020-06-02 22:47 ` [Tarantool-patches] [PATCH 0/3] Merger's NULL defererence Vladislav Shpilevoy 2020-06-07 17:17 ` Alexander Turenko 2020-06-07 16:58 ` [Tarantool-patches] [PATCH 2.5/3] merger: clean fiber-local Lua stack after next() Alexander Turenko 2020-06-11 16:20 ` Vladislav Shpilevoy 2020-06-17 17:53 ` Alexander Turenko 2020-06-18 22:48 ` Vladislav Shpilevoy 2020-06-19 7:41 ` Alexander Turenko [this message] 2020-06-17 17:54 ` [Tarantool-patches] [PATCH 0/3] Merger's NULL defererence Alexander Turenko
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200619074122.7ijjpgqkmqtdbxpq@tkn_work_nb \ --to=alexander.turenko@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH 2.5/3] merger: clean fiber-local Lua stack after next()' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox