From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <f.ebner@proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id A343060E22 for <pve-devel@lists.proxmox.com>; Thu, 17 Feb 2022 15:10:27 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 91DF1202BF for <pve-devel@lists.proxmox.com>; Thu, 17 Feb 2022 15:10:27 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 1A5E8202B3 for <pve-devel@lists.proxmox.com>; Thu, 17 Feb 2022 15:10:27 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id DBD8A46DE8 for <pve-devel@lists.proxmox.com>; Thu, 17 Feb 2022 15:10:26 +0100 (CET) Message-ID: <28836632-339c-3c81-e7ae-9c1b2fdeaadd@proxmox.com> Date: Thu, 17 Feb 2022 15:10:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Mira Limbeck <m.limbeck@proxmox.com>, pve-devel@lists.proxmox.com References: <20220217125543.290795-1-m.limbeck@proxmox.com> <4de26b7e-8601-b025-8afd-5b96116d2c03@proxmox.com> <1a7e27b6-5b12-d075-5ef0-e27a99820699@proxmox.com> From: Fabian Ebner <f.ebner@proxmox.com> In-Reply-To: <1a7e27b6-5b12-d075-5ef0-e27a99820699@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.134 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record T_SCC_BODY_TEXT_LINE -0.01 - Subject: Re: [pve-devel] [PATCH storage] fix #3894: file 'size' and 'used' are not integers X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/> List-Post: <mailto:pve-devel@lists.proxmox.com> List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe> X-List-Received-Date: Thu, 17 Feb 2022 14:10:27 -0000 Am 17.02.22 um 14:33 schrieb Mira Limbeck: > On 2/17/22 14:24, Fabian Ebner wrote: >> Am 17.02.22 um 13:55 schrieb Mira Limbeck: >>> 'qemu-img info' with output format 'json' returns the size and used >>> values as >>> integers, but the regex match converts them to strings. >>> As we know they only contain digits, we can simply cast them back to >>> integers >>> after the regex. >>> >>> The API requires them to be integers. >>> >> Any reason for not doing it in the API call itself? That would cover all >> plugins and future changes. > > The main reason is that we call volume_size_info (which forwards to > file_size_info in most cases) and file_size_info in other parts of our > code as well. Wouldn't it be more consistent for `size` and `used` to be > integers in every context, rather than just in that specific API call? It doesn't hurt to do it, but it's not persistent, because Perl has no real types. If it's used as a string some time later (e.g. printed), it'll be a "string" again. When converting to JSON, the result depends on how the variable was last used, so IMHO it should happen as close to that point as possible. > > We could add an additional cast in the API call as well to make sure > other and future plugins don't run into the same issues. >