Tarantool development patches archive
 help / color / mirror / Atom feed
From: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
To: "n.pettik" <korablev@tarantool.org>, tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH 6/6] sql: allow to specify UNSIGNED column type
Date: Thu, 11 Jul 2019 00:49:38 +0200	[thread overview]
Message-ID: <9a397d31-1cae-0dd0-cdd6-733388cb01af@tarantool.org> (raw)
In-Reply-To: <734EC309-6DCF-42C2-8041-135A8B68E935@tarantool.org>

Thanks for the fixes!

>> --------------------------------------------------------------
>> vdbeaux.c:2998:
>> 		if ((f1 & MEM_UInt) != 0) {
>> 			if ((f2 & MEM_Real) != 0) {
>> 				return sqlIntFloatCompare(pMem1->u.i,
>>
>> pMem1 is unsigned, according to the first check,
>> but you use u.i. Why?
> 
> Thx, I’ve fixed series of similar places and extended sql/types.test.lua:
> 
> diff --git a/src/box/sql/vdbeaux.c b/src/box/sql/vdbeaux.c
> index 325c54c18..b6b5cd0bf 100644
> --- a/src/box/sql/vdbeaux.c
> +++ b/src/box/sql/vdbeaux.c
> @@ -2887,43 +2887,50 @@ sqlBlobCompare(const Mem * pB1, const Mem * pB2)
>         return n1 - n2;
>  }
>  
> -/*
> - * Do a comparison between a 64-bit signed integer and a 64-bit floating-point
> - * number.  Return negative, zero, or positive if the first (i64) is less than,
> - * equal to, or greater than the second (double).
> +/**
> + * Do a comparison between a 64-bit unsigned/signed integer and a
> + * 64-bit floating-point number.  Return negative, zero, or
> + * positive if the first (integer) is less than, equal to, or
> + * greater than the second (double).
>   */
>  static int
> -sqlIntFloatCompare(i64 i, double r)
> +compare_uint_float(uint64_t u, double r)

Unfortunately, it is not as simple as you implemented it.
See mp_compare_double_uint64 in tuple_compare.cc for details.
In short, your function works wrong when numbers are near
uint maximum. Perhaps, it is worth moving this comparator
from tuple_compare.cc to a header. Like trivia/util.h.

>  {
> -       if (sizeof(LONGDOUBLE_TYPE) > 8) {
> -               LONGDOUBLE_TYPE x = (LONGDOUBLE_TYPE) i;
> -               if (x < r)
> -                       return -1;
> -               if (x > r)
> -                       return +1;
> -               return 0;
> -       } else {
> -               i64 y;
> -               double s;
> -               if (r < -9223372036854775808.0)
> -                       return +1;
> -               if (r > 9223372036854775807.0)
> -                       return -1;
> -               y = (i64) r;
> -               if (i < y)
> -                       return -1;
> -               if (i > y) {
> -                       if (y == SMALLEST_INT64 && r > 0.0)
> -                               return -1;
> -                       return +1;
> -               }
> -               s = (double)i;
> -               if (s < r)
> -                       return -1;
> -               if (s > r)
> -                       return +1;
> -               return 0;
> -       }
> +       if (r > (double) UINT64_MAX)
> +               return -1;
> +       if (r < 0.0)
> +               return +1;
> +       uint64_t y = (uint64_t) r;
> +       if (u < y)
> +               return -1;
> +       if (u > y)
> +               return +1;
> +       double s = (double) u;
> +       if (s < r)
> +               return -1;
> +       if (s > r)
> +               return +1;
> +       return 0;
> +}
> +
> +static int
> +compare_int_float(int64_t i, double r)

It has the same problems as the previous function,
but can be fixed by calling compare_uint_float()
with a modulo of 'int64_t i' and reversed result,
if the value was negative. This is what mp_compare_double_any_int
does.

> +{
> +       if (r < (double) INT64_MIN)
> +               return +1;
> +       if (r >= 0.0)
> +               return -1;
> +       int64_t y = (int64_t) r;
> +       if (i < y)
> +               return -1;
> +       if (i > y)
> +               return +1;
> +       double s = (double) i;
> +       if (s < r)
> +               return -1;
> +       if (s > r)
> +               return +1;
> +       return 0;
>  }
>> --------------------------------------------------------------
>> vdbemem.c:1431:
>> 			} else if (pVal->u.i == SMALLEST_INT64) {
>> 				pVal->u.r = -(double)SMALLEST_INT64;
>> 				MemSetTypeFlag(pVal, MEM_Real);
>> 			} else {
>> 				pVal->u.i = -pVal->u.i;
>> 			}
>>
>> You compare u.i and SMALLEST_INT64, but you can't
>> be sure, that u.i is not a big unsigned, can you?
> 
> Fixed:
> 
> diff --git a/src/box/sql/vdbemem.c b/src/box/sql/vdbemem.c
> index f8673912e..64acb5d41 100644
> --- a/src/box/sql/vdbemem.c
> +++ b/src/box/sql/vdbemem.c
> @@ -1428,11 +1428,15 @@ valueFromExpr(sql * db, /* The database connection */
>                                 return rc;
>                         if (pVal->flags & MEM_Real) {
>                                 pVal->u.r = -pVal->u.r;
> -                       } else if (pVal->u.i == SMALLEST_INT64) {
> -                               pVal->u.r = -(double)SMALLEST_INT64;
> -                               MemSetTypeFlag(pVal, MEM_Real);
> -                       } else {
> -                               pVal->u.i = -pVal->u.i;
> +                       } else if ((pVal->flags & MEM_Int) != 0) {
> +                               mem_set_u64(pVal, (uint64_t)(-pVal->u.i));
> +                       } else if ((pVal->flags & MEM_UInt) != 0) {
> +                               if (pVal->u.u > (uint64_t) INT64_MAX + 1) {
> +                                       pVal->u.r = -(double) pVal->u.u;
> +                                       MemSetTypeFlag(pVal, MEM_Real);

Won't we have a problem here, that an expression '--value' won't be
equal to 'value' in case the value is bigger than INT64_MAX + 1?

> +                               } else {
> +                                       mem_set_i64(pVal, (int64_t)(-pVal->u.u));
> +                               }
>                         }
>                         sql_value_apply_type(pVal, type);
>                 }
> 

Note for Kirill: this is not a final review. I will get back a bit later to
check other places where Mem.u.u, Mem.u.i, MEM_UInt, MEM_Int are used.

  reply	other threads:[~2019-07-10 22:48 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-07 15:37 [tarantool-patches] [PATCH 0/6] Introduce UNSIGNED type in SQL Nikita Pettik
2019-06-07 15:37 ` [tarantool-patches] [PATCH 1/6] sql: refactor sql_atoi64() Nikita Pettik
2019-06-11 21:11   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-01 14:20     ` n.pettik
2019-07-01 21:53       ` Vladislav Shpilevoy
2019-07-05 16:32         ` n.pettik
2019-06-07 15:37 ` [tarantool-patches] [PATCH 2/6] sql: separate VDBE memory holding positive and negative ints Nikita Pettik
2019-06-11 21:11   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-01 14:21     ` n.pettik
2019-07-01 21:53       ` Vladislav Shpilevoy
2019-07-05 16:33         ` n.pettik
2019-06-07 15:37 ` [tarantool-patches] [PATCH 3/6] sql: refactor arithmetic operations to support unsigned ints Nikita Pettik
2019-06-11 21:11   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-01 14:21     ` n.pettik
2019-07-01 21:53       ` Vladislav Shpilevoy
2019-07-05 16:36         ` n.pettik
2019-07-10 22:49           ` Vladislav Shpilevoy
2019-07-17 12:24             ` n.pettik
2019-06-07 15:37 ` [tarantool-patches] [PATCH 4/6] sql: make built-in functions operate on unsigned values Nikita Pettik
2019-06-11 21:11   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-01 14:21     ` n.pettik
2019-07-01 21:53       ` Vladislav Shpilevoy
2019-07-05 16:36         ` n.pettik
2019-07-10 22:49           ` Vladislav Shpilevoy
2019-07-17  0:53             ` n.pettik
2019-06-07 15:37 ` [tarantool-patches] [PATCH 5/6] sql: introduce extended range for INTEGER type Nikita Pettik
2019-06-11 21:11   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-01 14:21     ` n.pettik
2019-07-01 21:53       ` Vladislav Shpilevoy
2019-07-24 15:59   ` Konstantin Osipov
2019-07-24 16:54     ` n.pettik
2019-07-24 17:09       ` Konstantin Osipov
2019-06-07 15:37 ` [tarantool-patches] [PATCH 6/6] sql: allow to specify UNSIGNED column type Nikita Pettik
2019-07-01 21:53   ` [tarantool-patches] " Vladislav Shpilevoy
2019-07-05 16:36     ` n.pettik
2019-07-10 22:49       ` Vladislav Shpilevoy [this message]
2019-07-11 21:25         ` Vladislav Shpilevoy
2019-07-17  0:53           ` n.pettik
2019-07-18 20:18             ` Vladislav Shpilevoy
2019-07-18 20:56               ` n.pettik
2019-07-18 21:08                 ` Vladislav Shpilevoy
2019-07-18 21:13                   ` Vladislav Shpilevoy
2019-07-22 10:20                     ` n.pettik
2019-07-22 19:17                       ` Vladislav Shpilevoy
2019-07-22 10:20                   ` n.pettik
2019-07-17  0:54         ` n.pettik
2019-07-18 20:18           ` Vladislav Shpilevoy
2019-08-06 19:36         ` n.pettik
2019-07-24 13:01 ` [tarantool-patches] Re: [PATCH 0/6] Introduce UNSIGNED type in SQL Kirill Yukhin

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=9a397d31-1cae-0dd0-cdd6-733388cb01af@tarantool.org \
    --to=v.shpilevoy@tarantool.org \
    --cc=korablev@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH 6/6] sql: allow to specify UNSIGNED column type' \
    /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