[Tarantool-patches] [PATCH v4 02/16] sql: fix possible undefined behavior during cast

[Vladislav Shpilevoy]

Thanks for the fixes!

On 01.10.2021 14:48, imeevma at tarantool.org wrote:
> This patch fixes possible undefined behavior during the implicit cast of
> INTEGER to DOUBLE. The problem is, if the INTEGER is close enough to
> 2^64, it will be cast to 2^64 when it is cast to DOUBLE. Since we have a
> check for loss of precision, this will cause this DOUBLE to be cast to
> an INTEGER, which will result in undefined behavior since this DOUBLE is
> outside the range of INTEGER.
> ---
>  src/box/sql/mem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/box/sql/mem.c b/src/box/sql/mem.c
> index 24d6d7dbf..079083fa1 100644
> --- a/src/box/sql/mem.c
> +++ b/src/box/sql/mem.c
> @@ -682,7 +682,7 @@ uint_to_double_precise(struct Mem *mem)
>  	assert(mem->type == MEM_TYPE_UINT);
>  	double d;
>  	d = (double)mem->u.u;
> -	if (mem->u.u != (uint64_t)d)
> +	if (d == (double)UINT64_MAX || mem->u.u != (uint64_t)d)

What if uint really was UINT64_MAX? Then you treat its conversion
into UINT64_MAX double as an error?

Maybe we could simply refuse to convert all ints > 2^53 and <-2^53
(or whatever is the precise int limit in double). All ints above
these values will convert 'from time to time' depending on exact
values, which does not look reliable anyway.