From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753990AbbGAOxy (ORCPT ); Wed, 1 Jul 2015 10:53:54 -0400 Received: from smtprelay0088.hostedemail.com ([216.40.44.88]:49404 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753168AbbGAOxr (ORCPT ); Wed, 1 Jul 2015 10:53:47 -0400 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,joe@perches.com,:::::::::::::,RULES_HIT:41:355:379:541:599:973:988:989:1260:1277:1311:1313:1314:1345:1359:1373:1437:1500:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2198:2199:2393:2553:2559:2562:2693:2828:3138:3139:3140:3141:3142:3355:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:4250:4321:5007:6261:7903:8957:10004:10400:10848:11026:11232:11473:11658:11914:12043:12296:12438:12517:12519:12679:12740:13161:13229:13618:21080,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0 X-HE-Tag: van86_3de9aa7eced25 X-Filterd-Recvd-Size: 3985 Message-ID: <1435762424.12101.95.camel@perches.com> Subject: Re: RFC: kernel coding style: prefer array to &array[0] ? From: Joe Perches To: Julia Lawall Cc: Dan Carpenter , Clemens Ladisch , LKML , Andrew Morton , Liam Girdwood , Mark Brown Date: Wed, 01 Jul 2015 07:53:44 -0700 In-Reply-To: References: <1435685746.12101.18.camel@perches.com> <5593D4F5.1090106@ladisch.de> <20150701121524.GA30834@mwanda> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.12.11-0ubuntu3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2015-07-01 at 14:26 +0200, Julia Lawall wrote: > On Wed, 1 Jul 2015, Dan Carpenter wrote: > > On Wed, Jul 01, 2015 at 01:54:29PM +0200, Clemens Ladisch wrote: > > > Joe Perches wrote: > > > > It seems most in-kernel uses are 'array' rather than '&array[0]' > > > > > > > > Most of the time, using array is simpler to read than &array[0]. > > > > > > > > Exceptions exists when addresses for consecutive members are > > > > used like func(&array[0], &array[1]); > > > > > > I use '&array[0]' when I want to get a pointer to a single object that > > > happens to be the first one in an array. > > > > Yeah. Of course, you're right. Otherwise it ends up confusing static > > checkers if you want the first element or the whole array. Right. > > > > Should this preference be put into checkpatch and/or CodingStyle? And checkpatch will have no idea what the prototype for any function is, so this transform is better left for smarter tools like coccinelle. The proper answer here is no. > > > How about the following low-hanging fruit? > > > > > > foo(..., &array[0], ARRAY_SIZE(array), ...) > > > > Yes, to this also. I doubt checkpatch.pl will find a meaningful number > > of these but doing that is annoying thing. > > Atcually, I find 236 of them, in 48 files. The uses I found: drivers/input/touchscreen nas a few There are some inconsistent uses of 1 vs ARRAY_SIZE in drivers/mfd/ for "struct mfc_cell" arrays uses for mfd_add_devices() 2 in net/netfilter/xt_l2tp.c that could be changed sound/pci has a couple sound/soc/codecs has the rest. These are all the same form where a macro like SND_SOC_DAPM_MIXER is used. An example: #define SND_SOC_DAPM_MIXER(wname, wreg, wshift, winvert, \ wcontrols, wncontrols)\ { .id = snd_soc_dapm_mixer, .name = wname, \ SND_SOC_DAPM_INIT_REG_VAL(wreg, wshift, winvert), \ .kcontrol_news = wcontrols, .num_kcontrols = wncontrols} but is used with wcontrols as either NULL or an array and ARRAY_SIZE can't be used on NULL. Perhaps it's appropriate to change the macro (and uses) removing the last wncontrols argument. Something like: #define SND_SOC_DAPM_MIXER(wname, wreg, wshift, winvert, wcontrols) \ { \ .id = snd_soc_dapm_mixer, \ .name = wname, \ SND_SOC_DAPM_INIT_REG_VAL(wreg, wshift, winvert), \ .kcontrol_news = wcontrols, \ .num_kcontrols = (wcontrols) ? ARRAY_SIZE(wcontrols) : 0, \ } for example, the uses change from: SND_SOC_DAPM_MIXER("HPOut Mix", SND_SOC_NOPM, 0, 0, NULL, 0), to: SND_SOC_DAPM_MIXER("HPOut Mix", SND_SOC_NOPM, 0, 0, NULL), and from: SND_SOC_DAPM_MIXER("Mono Mixer", SND_SOC_NOPM, 0, 0, da7210_dapm_monomix_controls, ARRAY_SIZE(da7210_dapm_monomix_controls)), to: SND_SOC_DAPM_MIXER("Mono Mixer", SND_SOC_NOPM, 0, 0, da7210_dapm_monomix_controls), or just leave them as-is.