[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <SN1PR0101MB1565D3FCA22C6E4C06766279D09D0@SN1PR0101MB1565.prod.exchangelabs.com>
Date: Thu, 15 Dec 2016 16:12:20 +0000
From: Hartley Sweeten <HartleyS@...ionengravers.com>
To: Ian Abbott <abbotti@....co.uk>,
Piotr Gregor <piotrgregor@...ncme.org>
CC: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"devel@...verdev.osuosl.org" <devel@...verdev.osuosl.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] drivers: staging: comedi: fix function prototypes
On Thursday, December 15, 2016 4:47 AM, Ian Abbott wrote:
> On 14/12/16 16:14, Hartley Sweeten wrote:
>> On December 14, 2016 6:42 AM, Piotr Gregor wrote:
>>> -struct pci_dev *comedi_to_pci_dev(struct comedi_device *);
>>> +struct pci_dev *comedi_to_pci_dev(struct comedi_device *dev);
>>
>> For the function prototypes I prefer no names for the "pointer" parameters.
>>
>> The "struct foo *" declaration is just as clear as "struct foo *bar".
>
> Maybe, but checkpatch.pl doesn't agree (not since commit
> ca0d8929e75ab1f860f61208d46955f280a1b05e anyway)!
Hmm.. Missed seeing that one go in.
I still think it's silly to name struct pointers in function arguments.
Especially since that normally leads to stuff like 'struct foo *foo' where
the parameter name is the same as the struct name.
Void pointers and generic types are a different matter. Naming those
makes sense for clarity.
Oh well... Just my 2 cents...
Hartley
Powered by blists - more mailing lists