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
| ||
|
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