From: Dan Carpenter <error27@gmail.com>
To: Brent Pappas <bpappas@pappasbrent.com>
Cc: sakari.ailus@linux.intel.com, bingbu.cao@intel.com,
tian.shu.qiu@intel.com, mchehab@kernel.org,
gregkh@linuxfoundation.org, linux-media@vger.kernel.org,
linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mdeia: ipu3: ipu33-mmu: Replace macro IPU3_ADDR2PTE() with a function
Date: Wed, 25 Jan 2023 18:27:01 +0300 [thread overview]
Message-ID: <Y9FKRQiiUxCsidhe@kadam> (raw)
In-Reply-To: <Y9E+dGgQXFUQnIb8@pappasbrent.com>
I'm sorry, but I don't think this is a worthwhile approach.
If you created a tool to automatically re-write macros as functions,
that's super impressive. But the choice between using a macro and a
function is just a style debate. The note in Coding Style is more
talking about complicated macros instead of these simple ones. And
anyway, when it comes to gray areas in the style guidelines, we
generally defer to the original author because that's who is doing all
the work.
There are some sorts of bugs associated with using macros like Macro
Expansion Precedence Bugs where there isn't parentheses around a macro,
or Double Evaluation Bugs where a parameter is evaluated twice. But
these sorts of bugs are very rare in the Linux kernel. Generally kernel
programmers have always been good about this sort of stuff. Also
checkpatch insists on parentheses. And it's not like error paths where
the bugs are difficult to find in testing. Probably we get a macro
bug every three years (compared to uninitialized variable bugs where we
get several per week). I have a Smatch check for both of these kinds of
macro bugs.
Another kind of bug would be type related bugs, because macros don't
have type checking. But I think those are caught in testing so they're
extremely rare. I don't think I have seen a real life example of one of
those.
regards,
dan carpenter
prev parent reply other threads:[~2023-01-25 15:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-24 13:55 [PATCH] mdeia: ipu3: ipu33-mmu: Replace macro IPU3_ADDR2PTE() with a function Brent Pappas
2023-01-24 14:42 ` Dan Carpenter
2023-01-25 14:36 ` Brent Pappas
2023-01-25 15:27 ` Dan Carpenter [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=Y9FKRQiiUxCsidhe@kadam \
--to=error27@gmail.com \
--cc=bingbu.cao@intel.com \
--cc=bpappas@pappasbrent.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-staging@lists.linux.dev \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=tian.shu.qiu@intel.com \
/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