From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alyapunov@tarantool.org>
Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149])
 (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 0C0B3445320
 for <tarantool-patches@dev.tarantool.org>;
 Mon,  6 Jul 2020 16:39:50 +0300 (MSK)
References: <1593757997-4145-1-git-send-email-alyapunov@tarantool.org>
 <1593757997-4145-3-git-send-email-alyapunov@tarantool.org>
 <0ce23cdd-5a37-e1a3-3b3c-c949120c9e96@tarantool.org>
From: Aleksandr Lyapunov <alyapunov@tarantool.org>
Message-ID: <e124af3e-060f-c0c7-c354-895da9deda13@tarantool.org>
Date: Mon, 6 Jul 2020 16:39:50 +0300
MIME-Version: 1.0
In-Reply-To: <0ce23cdd-5a37-e1a3-3b3c-c949120c9e96@tarantool.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Subject: Re: [Tarantool-patches] [PATCH 02/15] Check data_offset overflow in
 struct tuple
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, tarantool-patches@dev.tarantool.org

Thank for the review.

On 05.07.2020 20:03, Vladislav Shpilevoy wrote:
> +i1 = s:create_index('pk')
>> + | ---
>> + | ...
>> +i2 = s:create_index('mk', {parts={{'[2][*]', 'uint'}}})
> 1. Why do you need a multikey index? This test lacks a comment.
Mutlikey index creates a variadic-length offset table in a tuple.
That is a simplest way to overflow it.
Sure, I'll add a comment.
>> diff --git a/test/box/huge_field_map_long.test.lua b/test/box/huge_field_map_long.test.lua
>> new file mode 100644
> 3. Why do you need a 'long' test? The first test seems to be good enough.

It's just another way to overflow offset table. For example 1.10 does not
have multikey indexes, so only long test will crash it. And perhaps 
we'll merge
into 1.10.
There's also a chance that we'll fix 
https://github.com/tarantool/tarantool/issues/5085
and multikey test will not work.