From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id D899522BCF for ; Mon, 1 Jul 2019 17:52:11 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIAVK1TnMgFL for ; Mon, 1 Jul 2019 17:52:11 -0400 (EDT) Received: from smtp53.i.mail.ru (smtp53.i.mail.ru [94.100.177.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id 9AAC022BB6 for ; Mon, 1 Jul 2019 17:52:11 -0400 (EDT) Subject: [tarantool-patches] Re: [PATCH 4/6] sql: make built-in functions operate on unsigned values References: <4acf9fab112e7ca119f1b2bf5efea53b3831ea4f.1559919361.git.korablev@tarantool.org> <4cbc3612-b655-8b2b-d879-6b1445c9535b@tarantool.org> <947FF2ED-8FBF-4796-8CFB-C12BE610A90A@tarantool.org> From: Vladislav Shpilevoy Message-ID: Date: Mon, 1 Jul 2019 23:53:10 +0200 MIME-Version: 1.0 In-Reply-To: <947FF2ED-8FBF-4796-8CFB-C12BE610A90A@tarantool.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: "n.pettik" , tarantool-patches@freelists.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?