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 C7ADB2B96E for ; Mon, 29 Oct 2018 08:15:30 -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 wGI_6l_tn43A for ; Mon, 29 Oct 2018 08:15:30 -0400 (EDT) Received: from smtpng3.m.smailru.net (smtpng3.m.smailru.net [94.100.177.149]) (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 7EDF727CAA for ; Mon, 29 Oct 2018 08:15:30 -0400 (EDT) Date: Mon, 29 Oct 2018 15:15:29 +0300 From: Alexander Turenko Subject: [tarantool-patches] Re: [PATCH 2/2] sql: remove GLOB from Tarantool Message-ID: <20181029121529.2d6ccnh5qayiz7ld@tkn_work_nb> References: <4607dc428909e96915e9f0984a7733a0890a3185.1534436836.git.n.tatunov@tarantool.org> <76466086-2a5f-8f12-cbc3-4ddf26e30fd9@tarantool.org> <32D1E5EA-EA21-4E4B-B5F5-80B6578BFBED@tarantool.org> <3f8354cb-4a47-c3de-164b-c776c792b991@tarantool.org> <090683CD-6F88-492D-AF48-631220A24E36@tarantool.org> <20181021034805.alwhmkpz3fbopqjz@tkn_work_nb> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: Nikita Tatunov Cc: tarantool-patches@freelists.org, korablev@tarantool.org Hi! See remaining comments below. WBR, Alexander Turenko. > >> +static const int case_insensitive_like = 1; > >> +static const int case_sensitive_like = 0; > > > > Are not they are mutually exclusive? Can we leave just one? > > > > Why they are not defines? > > I guess it’s a bad idea since we need pointers to them in some functions. > e.g: > > int *is_like_ci; > if (is_case_sensitive) > is_like_ci = (void *)&case_sensitive_like; > else > is_like_ci = (void *)&case_insensitive_like; > sqlite3CreateFunc(db, "LIKE", 2, 0, is_like_ci, likeFunc, 0, 0, 0); > sqlite3CreateFunc(db, "LIKE", 3, 0, is_like_ci, likeFunc, 0, 0, 0); I think we can use SQLITE_INT_TO_PTR and SQLITE_PTR_TO_INT to pass an integer value as a pointer and then cast it back. Maybe we also should change LIKEFUNC macro. > >> + int *is_like_ci; > >> + if (is_case_sensitive) > >> + is_like_ci = (int *)&case_sensitive_like; > >> + else > >> + is_like_ci = (int *)&case_insensitive_like; > > > > Discarding const qualifier? It seems not being right thing to do. It is > > better to define is_like_ci pointer as const. > > It’s not possible due to so-called “down qualification” and will cause > compiler warnings. We'll anyway discard it here or there, so nevermind. I proposed to change it to SQLITE_INT_TO_PTR.