From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joe Perches Date: Wed, 18 Oct 2017 11:49:43 +0000 Subject: Re: Adjusting further size determinations? Message-Id: <1508327383.6806.7.camel@perches.com> List-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> <1508322510.6806.3.camel@perches.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: SF Markus Elfring , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Cc: Julia Lawall , Alexander.Steffen@infineon.com, James Bottomley , Dan Carpenter , Jarkko Sakkinen , Andy Shevchenko , Benjamin Herrenschmidt , Corentin Labbe , Jason Gunthorpe , Jerry Snitselaar , Kenneth Goldman , Michael Ellerman , Nayna Jain , Paul Mackerras , Peter =?ISO-8859-1?Q?H=FCwe?= , Stefan Berger , linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org On Wed, 2017-10-18 at 13:00 +0200, SF Markus Elfring wrote: > > 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)), > > Would you like to get this ratio changed in any ways? No. > Available development tools could help to improve the software situation > in a desired direction, couldn't they? > > > Unpleasant consequences are possible in both cases. > How much do you care to reduce the failure probability further? Zero. The alloc style is trivially useful for new code. Existing code doesn't need change. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtprelay0174.hostedemail.com ([216.40.44.174]:36709 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754386AbdJRLtt (ORCPT ); Wed, 18 Oct 2017 07:49:49 -0400 Message-ID: <1508327383.6806.7.camel@perches.com> Subject: Re: Adjusting further size determinations? From: Joe Perches To: SF Markus Elfring , linux-integrity@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Cc: Julia Lawall , Alexander.Steffen@infineon.com, James Bottomley , Dan Carpenter , Jarkko Sakkinen , Andy Shevchenko , Benjamin Herrenschmidt , Corentin Labbe , Jason Gunthorpe , Jerry Snitselaar , Kenneth Goldman , Michael Ellerman , Nayna Jain , Paul Mackerras , Peter =?ISO-8859-1?Q?H=FCwe?= , Stefan Berger , linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org Date: Wed, 18 Oct 2017 04:49:43 -0700 In-Reply-To: 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> <1508322510.6806.3.camel@perches.com> Content-Type: text/plain; charset="ISO-8859-1" Mime-Version: 1.0 Sender: linux-integrity-owner@vger.kernel.org List-ID: On Wed, 2017-10-18 at 13:00 +0200, SF Markus Elfring wrote: > > 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)), > > Would you like to get this ratio changed in any ways? No. > Available development tools could help to improve the software situation > in a desired direction, couldn't they? > > > Unpleasant consequences are possible in both cases. > How much do you care to reduce the failure probability further? Zero. The alloc style is trivially useful for new code. Existing code doesn't need change.