Re: [Tarantool-patches] [PATCH v2 1/1] sql: limit blob size during CAST AS INTEGER

[Nikita Pettik <korablev@tarantool.org>]

On 22 Feb 11:27, Mergen Imeev wrote:
> Hi! Thank you for review. I changed a test once again.
> Diff below.
> 
> On Thu, Feb 20, 2020 at 10:58:21PM +0300, Nikita Pettik wrote:
> > On 13 Feb 11:16, imeevma@tarantool.org wrote:
> > So now you insert 0x33 instead of 1 to integer field. But how does it
> > affect test? I failed to understand. In both cases you fetch and operate
> > on blob, meanwhile integer field doesn't seem to be involved.
> > 
> As I wrote in the last letter, we have a way to make sure
> that with the first case everything will be in order,
> without creating a duplicate of this binary value.
> Obviously, that method will definitely not affect
> performance. But it can lead to the part of the value that
> looks like X'333300' being decoded as 33. See the example
> from the last letter.
> 
> 
> Diff:
> 
> diff --git a/test/sql-tap/cast.test.lua b/test/sql-tap/cast.test.lua
> index 86c0fee..74844e0 100755
> --- a/test/sql-tap/cast.test.lua
> +++ b/test/sql-tap/cast.test.lua
> @@ -891,13 +891,15 @@ test:do_execsql_test(
>  
>  --
>  -- In some cases, the absence of '\0' could lead to an incorrect
> --- result. Make sure this does not happen now.
> +-- result. For example, in this case, part of the value is as
> +-- follows: X'333300', which can be decoded as the number 33. Make
> +-- sure this does not happen now.
>  --
>  test:do_execsql_test(
>      "cast-6.2",
>      [[
> -        CREATE TABLE t (a VARBINARY PRIMARY KEY, i INT);
> -        INSERT INTO t VALUES (X'33', 0x33);
> +        CREATE TABLE t (a VARBINARY PRIMARY KEY, i INT, u INT);
> +        INSERT INTO t VALUES (X'33', 0x33, 0x00);

Still don't understand the purpose of creating separate table and so on.
Again: next/prev fields don't affect content of field 'A': blob is
stored in msgpack alongside with its length, so OP_Column can't decode
more/less bytes than indicated in msgpack.

What is more, found that your implementation relies on tt_cstr() which
uses static buffer which in turn restricted by 3 * 4096 bytes. So users
may get wrong results of cast with ease. Example:

long_str = string.rep('0', 15000) 
long_str = long_str..'123'
box.execute(string.format("insert into test values(2, '%s')", long_str)) 
box.execute("select cast(s as INTEGER) from test")

Result is 0 meanwhile should lead to error.