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]

Message-ID: <1508322510.6806.3.camel@perches.com>
Date:   Wed, 18 Oct 2017 03:28:30 -0700
From:   Joe Perches <joe@...ches.com>
To:     Julia Lawall <julia.lawall@...6.fr>, Alexander.Steffen@...ineon.com
Cc:     elfring@...rs.sourceforge.net, linux-integrity@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org,
        James.Bottomley@...senPartnership.comg, 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, 2017-10-18 at 12:00 +0200, Julia Lawall wrote:
> 
> 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.  The type argument to sizeof
> could have the wrong type.  The expression argument to sizeof could be
> missing the *.

Yup.

Today, even after all of Markus' patches for this style
conversion, there is still only ~2:1 preference for
	ptr = k.alloc(sizeof(*ptr))
over
	ptr = k.alloc(sizeof(struct foo))
in the kernel tree

Ugly grep follows:

$ grep -rohP --include=*.[ch] "\w+\s*=\s*[kv].alloc\s*\(\s*sizeof.*," * | \
  sed -r -e 's/(\w+)\s*=\s*[kv].alloc\s*\(\s*sizeof\s*\(\s*\*\s*\1\s*\)/foo = k.alloc(sizeof(*foo))/' \
         -e 's/(\w+)\s*=\s*[kv].alloc\s*\(\s*sizeof\s*\(\s*struct\s+\w+\s*\)/foo = k.alloc(sizeof(struct foo))/' | \
  sort | uniq -c | sort -rn | head -2
   6123 foo = k.alloc(sizeof(*foo)),
   3060 foo = k.alloc(sizeof(struct foo)),

> Unpleasant consequences are possible in both cases.

Yup.

> 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.  For example
> 
> if (...)
>   x = foo1(sizeof(struct xtype));
> else
>   x = foo2(sizeof(*x));
> 
> might at least cause some unnecessary mental effort to process.

Sure, but perhaps _only_ when there are inconsistencies
in the same compilation unit.'