Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85A58C7618B for ; Sat, 18 Mar 2023 17:15:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229821AbjCRRPg (ORCPT ); Sat, 18 Mar 2023 13:15:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46494 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229734AbjCRRPb (ORCPT ); Sat, 18 Mar 2023 13:15:31 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 08CBA558A; Sat, 18 Mar 2023 10:14:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 832FDB803F5; Sat, 18 Mar 2023 17:14:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79F9FC433EF; Sat, 18 Mar 2023 17:14:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1679159688; bh=CQpkawQkGuAV8PfhgbbB2HU74NKtyCwPubkAloZHHYY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=dz4HF5Hx9TT7waxUaZNhzhHHpWM5oLTkgvGftUuZ6aTvSwWGnmqsIpXRJS2KvSprg vAy0lgAzbNfltOcK/g4IzS4GWt6WhIvWSIvqKZEPGL6APixbGRYp0pQ0ZfFdHJFFaF mQZCUSxPLtRizIVlLKGN0XiFQPvzIr0YUMWw93YzpXdgJQza5MAORovic4qR6ebLQS lDBfmbiJ8ZPp/w6Jd2DSsL0GfmJYatoZWj3nS6VyzG/7D1iHQ4JELOPNDiv+LB6bAB eRObvbBHhnNsa67+DRGP5S1RUQQ42zK5YlS3OXsYpI2M+QQ/gvhnxlptriVij6K97M YJ99eu2/dy4qQ== Date: Sat, 18 Mar 2023 17:29:41 +0000 From: Jonathan Cameron To: Matti Vaittinen Cc: Andy Shevchenko , Matti Vaittinen , Lars-Peter Clausen , Shreeya Patel , Paul Gazzillo , Dmitry Osipenko , Zhigang Shi , linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org Subject: Re: [PATCH v3 2/6] iio: light: Add gain-time-scale helpers Message-ID: <20230318172941.36e41a79@jic23-huawei> In-Reply-To: References: X-Mailer: Claws Mail 4.1.1 (GTK 3.24.37; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > >>>> + kfree(gts->avail_all_scales_table); > > > > ... > > > >>>> + per_time_gains = kcalloc(gts->num_itime, sizeof(int *), GFP_KERNEL); > >>> > >>> sizeof(type) is error prone in comparison to sizeof(*var). > >> > >> Yes and no. In majority of cases where we see sizeof(*var) - the *var is no > >> longer a pointer as having pointers to pointers is not _that_ common. When > >> we see sizeof(type *) - we instantly know it is a size of a pointer and not > >> a size of some other type. > >> > >> So yes, while having sizeof(*var) makes us tolerant to errors caused by > >> variable type changes - it makes us prone to human reader errors. Also, if > >> someone changes type of *var from pointer to some other type - then he/she > >> is likely to in any case need to revise the array alloactions too. > >> > >> While I in general agree with you that the sizeof(variable) is better than > >> sizeof(type) - I see that in cases like this the sizeof(type *) is clearer. > > > > Still get a fundamental disagreement on this. I would insist, but I'm not > > a maintainer, so you are lucky :-) if Jonathan will not force you to follow > > my way. > > In a code you are maintaining it is good to have it in your way as > you're responsible for it. This is also why I insist on having things in > a way I can read best for a code I plan to maintain - unless the > subsystem maintainers see it hard to maintain for them. So, let's see if > Jonathan has strong opinions on this one :) This is one where I strongly prefer sizeof(*per_time_gains) because it's easier to review. I don't care so much if it's easier to modify as reality is these rarely get modified. I often just 'fix' these up whilst applying. Jonathan