linux-kernel - RE: char-TPM: Adjustments for ten function implementations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 18 Oct 2017 10:44:08 +0000
From:   <Alexander.Steffen@...ineon.com>
To:     <julia.lawall@...6.fr>
CC:     <joe@...ches.com>, <elfring@...rs.sourceforge.net>,
        <linux-integrity@...r.kernel.org>, <linuxppc-dev@...ts.ozlabs.org>,
        <James.Bottomley@...senPartnership.com>,
        <dan.carpenter@...cle.com>, <jarkko.sakkinen@...ux.intel.com>,
        <andriy.shevchenko@...ux.intel.com>, <benh@...nel.crashing.org>,
        <clabbe.montjoie@...il.com>, <jgunthorpe@...idianresearch.com>,
        <jsnitsel@...hat.com>, <kgold@...ux.vnet.ibm.com>,
        <mpe@...erman.id.au>, <nayna@...ux.vnet.ibm.com>,
        <paulus@...ba.org>, <PeterHuewe@....de>,
        <stefanb@...ux.vnet.ibm.com>, <linux-kernel@...r.kernel.org>,
        <kernel-janitors@...r.kernel.org>
Subject: RE: char-TPM: Adjustments for ten function implementations

> On Wed, 18 Oct 2017, Alexander.Steffen@...ineon.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