From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id B0DC768713; Mon, 1 Feb 2021 14:41:24 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org B0DC768713 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1612179684; bh=v8V5BY9CbHPRHC5Hx0AM1zJ/nt7S5aUWzEg9szMbR+c=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=CEDpRdBvnz7ofzxGReLfraAe72dhRdLOslH3QwvRjyto+FzOq0jxDvjUw06kHuOnj euPMufpmcef7yUtpCFVYU1QXJ4TpUOf4x4QUEHaEg3GKM4X+3FXSon/OwNbFFsgGhs tYcLr+Y9kOXNZ3H9cmEUtejxkj3gSjn0gt5tSgS8= Received: from mail-lj1-f172.google.com (mail-lj1-f172.google.com [209.85.208.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 9AA3F68713 for ; Mon, 1 Feb 2021 14:41:23 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 9AA3F68713 Received: by mail-lj1-f172.google.com with SMTP id v15so16163908ljk.13 for ; Mon, 01 Feb 2021 03:41:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=dfYyVvBw1rP/ERUdQb1Pi9ej1gkx3zKHRlS7F4vZHpI=; b=bT5VWKOOMXRSXxT/C4ZgDD42sHBzoebEOG2QRBg58pywsx4MQ/zTUsrc8pzVh0Vj1e F/P48UFFrd2h9wapU2+WPmtGe4AFitvXwRp8SsFlS7nSFW5XXvOufrKpyKbKRFuMGSQc C840VA+17fxmPYLqyY/JAGOagEX5tfJQKzyVW4MmcLHLxLfBgPG1r2kW/HKKqC7BWxhy aqf35LMXIBHmqbNKYbuI8YvowUTCEY2PUK55BaZk/iZbBXx7UfhaGpyHDfziddfQH41y XwSJOrV/bVDrrnt/h41D23oe3dAl4F+pxYqjhq7fZwhpjj9WUFzwxfXF/oryTiRE311D 7lIA== X-Gm-Message-State: AOAM5303gRG7aMb5P41GSv6gjb9AhxwapBSM058V1mnoA2sSO2q5OAP7 DjrkqZbnwzNLlUV6RFVOpQDkyBV/3qGb3Q== X-Google-Smtp-Source: ABdhPJyEuLEh21leZFD7CBB9qVzf8PkyFnr4U2uvHEpCZG41IZQIRoCZtTVNorINE/PGRI2g1eSvsg== X-Received: by 2002:a2e:9086:: with SMTP id l6mr10105032ljg.510.1612179682487; Mon, 01 Feb 2021 03:41:22 -0800 (PST) Received: from grain.localdomain ([5.18.103.226]) by smtp.gmail.com with ESMTPSA id b27sm620749lfo.267.2021.02.01.03.41.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 01 Feb 2021 03:41:21 -0800 (PST) Received: by grain.localdomain (Postfix, from userid 1000) id 0787B560119; Mon, 1 Feb 2021 14:41:20 +0300 (MSK) Date: Mon, 1 Feb 2021 14:41:20 +0300 To: Vladislav Shpilevoy Cc: tml Message-ID: <20210201114120.GC2172@grain> References: <20210118203556.281700-1-gorcunov@gmail.com> <20210118203556.281700-4-gorcunov@gmail.com> <03fe6138-05d8-a88d-eae5-05d060b54f7a@tarantool.org> <20210124223256.GD2174@grain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.14.6 (2020-07-11) Subject: Re: [Tarantool-patches] [PATCH v12 3/8] module_cache: improve naming X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Sat, Jan 30, 2021 at 07:53:03PM +0100, Vladislav Shpilevoy wrote: > Hi! > > On 24.01.2021 23:32, Cyrill Gorcunov wrote: > > On Sun, Jan 24, 2021 at 05:27:12PM +0100, Vladislav Shpilevoy wrote: > >> Thanks for the patch! > >> > >> Very dubious commit. To me the old and new names look the same. > >> 'func_name' was even better than 'func_name_desc'. At least > >> because it was shorter, and 'desc' does not add any more meaning. > >> > >> On 18.01.2021 21:35, Cyrill Gorcunov via Tarantool-patches wrote: > >>> - rename func_name to func_name_desc because > >>> it is not just a name but rather a name descriptor > >>> which includes symbol address > >> > >> I don't see any address in it. Only name tokens. > > > > struct func_name_desc { > > /** > > * Null-terminated symbol name, e.g. > > * "func" for "mod.submod.func". > > */ > > ---> const char *sym; > > /** > > * Package name, e.g. "mod.submod" for > > * "mod.submod.func". > > */ > > const char *package; > > /** > > * A pointer to the last character in ->package + 1. > > */ > > const char *package_end; > > }; > > > > I marked the address. > > You said "symbol address". But it is not a symbol address. It is > an address pointing at a part of the name string. Not at the > actual symbol, which you need to load later. This is an address of part of the string which represents symbol. When symbol is loaded it will have "resolved" address. Plain address and resolved address are pretty different things in loaders terminology. In real loaders initial address is position inside strings section which you're resolving later upon symbols lookup. We have the similar approach, except our initial address is position inside package string... > > > The structure is not a function name > > but consists of two parts - package path and function name > > itself and maybe something new will be added in future. > > In this case 'name desc' is also invalid - it does not describe > the name. Because there is also a path which is not a part of > the name. > > It would be more correct to call it func_path then. It is not a path. It is a *descriptor* which identify function in unique way on a storage device. But sure I will do struct func_path { const char *sym_name; const char *package; const char *package_end; }; > > > So func_name is suitable for plain names but not for strings > > where some part of it has a special meaning with hidden > > extension inside, hereby a descriptor. > > In this case you didn't really change it - it was about function > name and stayed about function name. It should be func_path then. > If you really want to rename. OK, I would prefer to rename. func_name already used in many places with rather plain string context, and forcing to use some fulltext search is not a good idea. To be honest I would keep func_name_desc here because the structure might extend in future but func_path fine as well. > > > And don't forget > > about grepability, without this name change grep returns > > a number of irrelevant results. > > This struct is defined and used in a single file. It is not that > hard to find it here. Especially if you use some smarter tools. > For instance, I use full text search in Sublime, and have never had > any issues with finding anything in Tarantool sources. Plus for > structs and functions you usually want to use ctags (Sublime also > generates these tags). Maybe it is only hard when you use command > line and bare grep.