From: Ryan Mallon <rmallon@gmail.com>
To: Joe Perches <joe@perches.com>
Cc: Phil Carmody <ext-phil.2.carmody@nokia.com>,
linux-kernel@vger.kernel.org, apw@canonical.com
Subject: Re: [PATCH 1/1] checkpatch: don't fake typedefs with #define
Date: Wed, 23 May 2012 12:50:02 +1000 [thread overview]
Message-ID: <4FBC505A.9000102@gmail.com> (raw)
In-Reply-To: <1337738520.13111.17.camel@joe2Laptop>
On 23/05/12 12:02, Joe Perches wrote:
> On Wed, 2012-05-23 at 11:54 +1000, Ryan Mallon wrote:
>> On 18/05/12 07:16, Phil Carmody wrote:
>>> Too many. Alas I can't share them.
>> That sounds like the cases you have seen are in code which is not
>> public. I don't think I have ever seen code in the kernel, or in
>> proposed patches which fakes a typedef with a #define.
>>
>> Is this an issue for public code, or for a private company tree? In the
>> latter case, the checkpatch addition should go in your private tree,
>> rather than mainline. It looks like, at least for mainline Linux, you
>> are trying to solve a non-existent problem.
>
> I agree it's pretty rare.
>
> $ git grep -E "#\s*define\s+\w+\s+(struct|union)\b"|wc -l
> 57
Some of those do look a bit broken, or easily replaced by typedefs.
Several of them appear to be completely unused. However some of them
look like they need to be defines. The ones in include/net/netfilter are
defines because of this:
#define nf_ct_ext_find(ext, id) \
((id##_TYPE *)__nf_ct_ext_find((ext), (id)))
This one:
#define __videocard struct card_info
__attribute__((section(".videocards")))
I'm guessing is because typedefs don't handle __attribute__.
The YYLTYPE one in scripts/dtc/srcpos.h I think is a requirement of
Yacc/Bison.
The acpi_cache_t looks a bit odd, but it is doing an ifdef acpi_cache_t
test (quick glance - looks like it allows a platform specific
definition), though that could probably be reworked to use a typedef and
a __ACPI_CACHE_T_DEFINED or something.
So there are some legitimate reasons for using #define instead of typedef.
However, my real point was that I don't think the problem is rampant. 57
instances across the kernel is not that many, and I haven't seen a lot
of patches trying to add code with #defines where typedefs should be
used. We could test for lots of things in checkpatch, but it seems more
sensible to check for issues which are likely.
~Ryan
next prev parent reply other threads:[~2012-05-23 2:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-17 12:52 [PATCH 1/1] checkpatch: don't fake typedefs with #define Phil Carmody
2012-05-17 20:54 ` Joe Perches
2012-05-17 21:16 ` Phil Carmody
2012-05-17 21:24 ` Joe Perches
2012-05-21 12:05 ` Phil Carmody
2012-05-21 16:41 ` Joe Perches
2012-05-22 8:01 ` Phil Carmody
2012-05-22 16:48 ` Joe Perches
2012-05-23 1:54 ` Ryan Mallon
2012-05-23 2:02 ` Joe Perches
2012-05-23 2:50 ` Ryan Mallon [this message]
2012-05-23 3:25 ` Joe Perches
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=4FBC505A.9000102@gmail.com \
--to=rmallon@gmail.com \
--cc=apw@canonical.com \
--cc=ext-phil.2.carmody@nokia.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.