Date:   Wed, 25 Jan 2023 18:27:01 +0300
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
Message-ID: <Y9FKRQiiUxCsidhe@kadam>
References: <20230124135554.13787-1-bpappas@pappasbrent.com>
 <Y8/uTYK7qmYD5MSA@kadam>
 <Y9E+dGgQXFUQnIb8@pappasbrent.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Y9E+dGgQXFUQnIb8@pappasbrent.com>
Precedence: bulk

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