Tarantool development patches archive
 help / color / mirror / Atom feed
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.

  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