From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp59.i.mail.ru (smtp59.i.mail.ru [217.69.128.39]) (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 6102C46970E for ; Wed, 18 Dec 2019 02:26:39 +0300 (MSK) Date: Wed, 18 Dec 2019 02:26:35 +0300 From: Alexander Turenko Message-ID: <20191217232635.hln5hjeeqbq2iquz@tkn_work_nb> References: <20191107103642.42377-1-maria.khaydich@tarantool.org> <20191111232132.vylt3ywr3ij7yx65@tkn_work_nb> <1575061766.543705524@f389.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1575061766.543705524@f389.i.mail.ru> Subject: Re: [Tarantool-patches] [PATCH] Msgpackffi considers msgpack.cfg options now List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Maria Khaydich Cc: tarantool-patches@dev.tarantool.org Sorry again for the late reply. > > I think we also should implement encode_sparse_* options to > > be compatible with msgpack module. > > Could you please explain how do you propose to implement them? It > seems to me the purpose of those configs is to handle excessively > sparse arrays as maps (as stated in src/lua/utils.h). Which does not > seem relevant to lua module where the only container type is table. > What do I miss here?  It is about encoding, not decoding: encode a Lua table with numeric keys as MP_ARRAY, MP_MAP or give an error. It seems that nothing prevent us from implementing this logic on Lua. > Subject: [PATCH 1/2] Msgpackffi considers msgpack.cfg options now > Msgpack.cfg options changes did not affect msgpackffi serializer state. > This patch fixes it for options encode_load_metatables, decode_ and > encode_invalid_numbers, encode_use_tostring and encode_invalid_as_nil. > Closes #4499 > --- > Issue: > https://github.com/tarantool/tarantool/issues/4499 > Branch: > https://github.com/tarantool/tarantool/compare/eljashm/gh-4499-msgpackffi-ignores-msgpack.cfg-options > @@ -261,6 +263,19 @@ local function encode_r(buf, obj, level) >          else >              error("Invalid __serialize value") >          end > +    elseif type(obj) == math.huge or type(obj) == -math.huge or  > +        type(obj) == math.nan then > +        if msgpack.cfg.encode_invalid_numbers then > +            if obj == math.huge then > +                obj = 1/0 > +            elseif obj == -math.huge then > +                obj = -1/0 > +            else > +                obj = 0/0 > +            end > +        else > +            encode_nil(buf) > +        end I would save 1/0, -1/0, 0/0 as module local variables for readability, like as it is done in test_double(). I also found that math.huge is 1/0 (inf) and there is no math.nan (it just nil). > @@ -562,6 +589,15 @@ decode_r = function(data) >      elseif c >= 0xe0 then >          return tonumber(ffi.cast('signed char',c)) -- negfixint >      elseif c == 0xc0 then > +        if msgpack.cfg.decode_invalid_numbers then > +            if c == 0/0 then > +                return math.nan > +            elseif c == 1/0 then > +                return math.huge > +            elseif c == -1/0 then > +                return -math.huge > +            end > +        end Same as above. > @@ -628,6 +664,8 @@ return { >      on_encode = on_encode; >      decode_unchecked = decode_unchecked; >      decode = decode_unchecked; -- just for tests > +    cfg = msgpack.cfg; > +    new = msgpack.new; -- for serializer tests to work properly So they'll test msgpack, not msgpackffi.