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 12:00:49 +0200 (CEST)
From:   Julia Lawall <julia.lawall@...6.fr>
To:     Alexander.Steffen@...ineon.com
cc:     joe@...ches.com, 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, 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 *.  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.  For example

if (...)
  x = foo1(sizeof(struct xtype));
else
  x = foo2(sizeof(*x));

might at least cause some unnecessary mental effort to process.

julia

Powered by blists - more mailing lists