From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Eugeniu Rosca <erosca@de.adit-jv.com>
Cc: kieran.bingham@ideasonboard.com, mchehab@kernel.org,
linux-media@vger.kernel.org, linux-renesas-soc@vger.kernel.org
Subject: Re: [PATCH] v4l: vsp1: Fix function declaration/definition mismatch
Date: Mon, 04 Dec 2017 21:03:20 +0200 [thread overview]
Message-ID: <5605020.PYOHkQC8tp@avalon> (raw)
In-Reply-To: <20171204181034.GA28598@vmlxhi-102.adit-jv.com>
Hi Eugeniu,
On Monday, 4 December 2017 20:10:34 EET Eugeniu Rosca wrote:
> On Mon, Dec 04, 2017 at 12:52:17PM +0200, Laurent Pinchart wrote:
> > On Friday, 24 November 2017 20:40:57 EET Kieran Bingham wrote:
> >> Hi Eugeniu,
> >>
> >> Thankyou for the patch,
> >>
> >> Laurent - Any comments on this? Otherwise I'll bundle this in with my
> >> suspend/resume patch for a pull request.
> >>
> >> <CUT>
> >>
> >> I was going to say: We know the object is an entity by it's type. Isn't
> >> hgo more descriptive for it's name ?
> >>
> >> However to answer my own question - The implementation function goes on
> >> to define a struct vsp1_hgo *hgo, so no ... the Entity object shouldn't
> >> be hgo.
> >
> > And that's exactly why there's a difference between the declaration and
> > implementation :-) Naming the parameter hgo in the declaration makes it
> > clear to the reader what entity is expected. The parameter is then named
> > entity in the function definition to allow for the vsp1_hgo *hgo local
> > variable.
> >
> > Is the mismatch a real issue ? I don't think the kernel coding style
> > mandates parameter names to be identical between function declaration and
> > definition.
>
> You are the DRM/VSP1 and kernel experts, so feel free to drop the patch.
> Still IMO what makes kernel coding style sweet is its simplicity [1].
> Here is some statistics computed with exuberant ctags and cpccheck.
>
> $ git describe HEAD
> v4.15-rc2
>
> $ ctags --version
> Exuberant Ctags 5.9~svn20110310, Copyright (C) 1996-2009 Darren Hiebert
> Addresses: <dhiebert@users.sourceforge.net>,
> http://ctags.sourceforge.net
> Optional compiled features: +wildcards, +regex
>
> # Number of function definitions in drivers/media:
> $ find drivers/media -type d | \
> xargs -I {} sh -c "ctags -x --c-types=f {}/*" | wc -l
> 24913
>
> # Number of func declaration/definition mismatches found by cppcheck:
> $ cppcheck --force --enable=all --inconclusive drivers/media/ 2>&1 | \
> grep declaration | wc -l
> 168
>
> It looks like only (168/24913) * 100% = 0,67% of all drivers/media
> functions have a mismatch between function declaration and function
> definition. Why making this number worse?
Of course the goal is not to introduce a mismatch for the sake of it. It makes
sense for the declaration and definition to match in most cases. My point is
that in this particular case I believe the mismatch makes the code more
readable.
--
Regards,
Laurent Pinchart
prev parent reply other threads:[~2017-12-04 19:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-20 12:40 [PATCH] v4l: vsp1: Fix function declaration/definition mismatch Eugeniu Rosca
2017-11-24 18:40 ` Kieran Bingham
2017-12-04 10:52 ` Laurent Pinchart
2017-12-04 18:10 ` Eugeniu Rosca
2017-12-04 19:03 ` Laurent Pinchart [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5605020.PYOHkQC8tp@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=erosca@de.adit-jv.com \
--cc=kieran.bingham@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=mchehab@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox