From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763243AbdJRKoN (ORCPT ); Wed, 18 Oct 2017 06:44:13 -0400 Received: from smtp2.infineon.com ([217.10.52.18]:49124 "EHLO smtp2.infineon.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753202AbdJRKoL (ORCPT ); Wed, 18 Oct 2017 06:44:11 -0400 X-SBRS: None From: To: CC: , , , , , , , , , , , , , , , , , , , Subject: RE: char-TPM: Adjustments for ten function implementations Thread-Topic: char-TPM: Adjustments for ten function implementations Thread-Index: AQHTR/AMDk4GC/dUGkChaZD4klU53qLpMssAgAAoH7D//+OhgIAAKRFQ Date: Wed, 18 Oct 2017 10:44:08 +0000 Message-ID: References: <1d3516a2-a8e6-9e95-d438-f115fac84c7f@users.sourceforge.net> <20171016183139.otyh3m5c5yurtmow@linux.intel.com> <20171016183512.3bz6x4b6lbhpbkje@linux.intel.com> <20171017085124.pkrjzghcf5wmcydc@mwanda> <1508255833.3129.33.camel@HansenPartnership.com> <1508280210.6530.32.camel@perches.com> <1508318326.6806.1.camel@perches.com> <026d582729b849b780fbaa06fb8bc79e@infineon.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.23.8.247] Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id v9IAiI8M009347 > On Wed, 18 Oct 2017, Alexander.Steffen@infineon.com wrote: > > > > On Wed, 2017-10-18 at 11:00 +0200, SF Markus Elfring wrote: > > > > > The printk removals do change the objects. > > > > > > > > > > The value of that type of change is only for resource limited systems. > > > > > > > > I imagine that such small code adjustments are also useful for other > > > systems. > > > > > > Your imagination and mine differ. > > > Where do you _think_ it matters? > > > > > > For instance, nothing about > > > > > > sizeof(type) > > > vs > > > sizeof(*ptr) > > > > > > makes it easier for a human to read the code. > > > > If it does not make it easier to read the code for you, then maybe you > > should consider that this might not be true for all humans. For me, it > > makes it much easier to see at a glance, that code like > > ptr=malloc(sizeof(*ptr)) is correct. > > I don't think there is a perfect solution. Maybe. But for the second variant the correctness is easier to check, both mentally and programmatically, because there is no need for any context (the type of ptr does not matter). > The type argument to sizeof > could have the wrong type. The expression argument to sizeof could be > missing the *. Unpleasant consequences are possible in both cases. > Probably each maintainer has a style they prefer. Perhaps it could be > useful to adjust the code to follow the dominant strategy, in cases where > there are a inconsistencies. Certainly. At least within a file, there should be only one style. > For example > > if (...) > x = foo1(sizeof(struct xtype)); > else > x = foo2(sizeof(*x)); > > might at least cause some unnecessary mental effort to process. > > julia Alexander