Re: [Tarantool-patches] [PATCH v5 45/52] sql: introduce mem_get_int()

[Vladislav Shpilevoy via Tarantool-patches <tarantool-patches@dev.tarantool.org>]

Nice fixes!

On 09.04.2021 22:53, Mergen Imeev via Tarantool-patches wrote:
> Thank you for the review! My answers and new patch below.
> 
> 
> On 30.03.2021 02:08, Vladislav Shpilevoy wrote:
>> Thanks for the patch!
>>
>>> diff --git a/src/box/sql/func.c b/src/box/sql/func.c
>>> index b644c39d8..0fa0f6ac7 100644
>>> --- a/src/box/sql/func.c
>>> +++ b/src/box/sql/func.c
>>> @@ -1532,10 +1543,11 @@ hexFunc(sql_context * context, int argc, sql_value ** argv)
>>>  static void
>>>  zeroblobFunc(sql_context * context, int argc, sql_value ** argv)
>>>  {
>>> -	i64 n;
>>> +	int64_t n;
>>>  	assert(argc == 1);
>>>  	UNUSED_PARAMETER(argc);
>>> -	n = sql_value_int64(argv[0]);
>>> +	bool unused;
>>> +	mem_get_integer(argv[0], &n, &unused);
>>
>> The flag is never used anywhere except one assertion where you can
>> check the integer value instead. I think you can drop this out
>> parameter. In future we could add mem_get_int_with_sign() or something
>> like that if necessary.
> I think the problem here mostly because most of built-in functions and bitwise
> operations cannot work with our INTEGER. They can only work with int64. I
> believe, if we fix this problem, there will be no problems with having this
> flag.

My complaint is about the flag. The third argument which is almost never
used. It makes the code ugly, and does not give a clue it is broken in fact.
When uint64_t is > INT64_MAX and is returned as int64_t and the flag is
ignored.

What about mem_get_int_unsafe()? It would return int64_t truncated like
before. Return as 'return', not out parameter. Because we also never check
for fail as I see. And no 'unused' flag. But we would clearly see that these
places are broken and need attention.