[tarantool-patches] Re: [PATCH 4/6] sql: make built-in functions operate on unsigned values

[Vladislav Shpilevoy <v.shpilevoy@tarantool.org>]

Thanks for the fixes!

On 01/07/2019 16:21, n.pettik wrote:
> 
>>> diff --git a/src/box/sql/func.c b/src/box/sql/func.c
>>> index 457c9b92b..365f8f9d2 100644
>>> --- a/src/box/sql/func.c
>>> +++ b/src/box/sql/func.c
>>> @@ -645,21 +638,13 @@ ICU_CASE_CONVERT(Upper);
>>> static void
>>> randomFunc(sql_context * context, int NotUsed, sql_value ** NotUsed2)
>>> {
>>> -	sql_int64 r;
>>> +	int64_t r;
>>> 	UNUSED_PARAMETER2(NotUsed, NotUsed2);
>>> 	sql_randomness(sizeof(r), &r);
>>> -	if (r < 0) {
>>> -		/* We need to prevent a random number of 0x8000000000000000
>>> -		 * (or -9223372036854775808) since when you do abs() of that
>>> -		 * number of you get the same value back again.  To do this
>>> -		 * in a way that is testable, mask the sign bit off of negative
>>> -		 * values, resulting in a positive value.  Then take the
>>> -		 * 2s complement of that positive value.  The end result can
>>> -		 * therefore be no less than -9223372036854775807.
>>> -		 */
>>> -		r = -(r & LARGEST_INT64);
>>> -	}
>>> -	sql_result_int64(context, r);
>>> +	if (r < 0)
>>> +		sql_result_int(context, r);
>>> +	else
>>> +		sql_result_uint(context, r);
>>
>> 1. To avoid such mess I propose you the same as for mem_set_int - make
>> several functions:
> 
> What kind of mess do you mean? Here we have two functions:
> one sets unsigned result, another one - signed. Pretty straight
> approach, isn’t it? What is more, this is the only place where
> branching is required.

If it is so straight, then why do you need branching at all?
I see, that sql_result_int() calls mem_set_i64, which is able
to take positive values.

I've done this and the tests passed. Why?

@@ -621,10 +621,7 @@ randomFunc(sql_context * context, int NotUsed, sql_value ** NotUsed2)
 	int64_t r;
 	UNUSED_PARAMETER2(NotUsed, NotUsed2);
 	sql_randomness(sizeof(r), &r);
-	if (r < 0)
-		sql_result_int(context, r);
-	else
-		sql_result_uint(context, r);
+	sql_result_int(context, r);
 }

> 
>>    /* Return an int64 value, sign is detected inside. */
>>    sql_result_i64(int64_t value);
>>
>>    /* Return a uint64 value. */
>>    sql_result_u64(uint64_t value);
>>
>>    /* Return an integer value with explicit sign. */
>>    sql_result_int(int64_t value, bool is_negative);
>>
>>> diff --git a/src/box/sql/sqlInt.h b/src/box/sql/sqlInt.h
>>> index c0e2ab699..4697e3003 100644
>>> --- a/src/box/sql/sqlInt.h
>>> +++ b/src/box/sql/sqlInt.h
>>> @@ -455,6 +455,9 @@ sql_column_subtype(struct sql_stmt *stmt, int i);
>>> sql_int64
>>> sql_value_int64(sql_value *);
>>>
>>> +uint64_t
>>> +sql_value_uint64(sql_value *val);
>>> +
>>> const unsigned char *
>>> sql_value_text(sql_value *);
>>>
>>> @@ -496,13 +499,13 @@ void
>>> sql_result_error_code(sql_context *, int);
>>>
>>> void
>>> -sql_result_int(sql_context *, int);
>>> +sql_result_int(sql_context *, int64_t);
>>>
>>> void
>>> -sql_result_bool(struct sql_context *ctx, bool value);
>>> +sql_result_uint(sql_context *ctx, int64_t u_val);
>>
>> 2. Why result_uint takes int instead of uint?
> 
> Because mem_set_int() accepts int64 and to avoid
> extra casts to uint (since almost al used values are singed).

This function has nothing to do with mem_set_int().
This function calls mem_set_u64(), and its argument is
unsigned. So what is a problem, again?