Re: [RFC PATCH 12/13] blk-mq.h: Fix parentheses around macro parameter use

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2023-05-04 16:05, Mathieu Desnoyers wrote:
Fix the following macro parameter usage patterns in blk-mq.h for
consistency, ensuring that operator precedence is respected:

Added parentheses:
[...]
- "x = y" is changed for "x = (y)", because "y" can be an expression
   containing a comma if it is the result of the expansion of a macro such
   as #define eval(...) __VA_ARGS__, which would cause unexpected operator
   precedence. This use-case is far-fetched, but we have to choose one
   way or the other (with or without parentheses) for consistency.

[...]

  include/linux/blk-mq.h | 38 +++++++++++++++++++-------------------
  1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/include/linux/blk-mq.h b/include/linux/blk-mq.h
index 06caacd77ed6..4de6ad92530c 100644
--- a/include/linux/blk-mq.h
+++ b/include/linux/blk-mq.h
@@ -223,13 +223,13 @@ static inline unsigned short req_get_ioprio(struct request *req)
#define rq_list_add(listptr, rq) do { \
  	(rq)->rq_next = *(listptr);			\
-	*(listptr) = rq;				\
+	*(listptr) = (rq);				\
  } while (0)


Linus,

Which way do we want to go with respect to the rvalue of the assignment operator "=" in a macro ? (with or without parentheses)

In short:

#define m(x) do { z = (x); } while (0)

or

#define m(x) do { z = x; } while (0)

?

Given that "=" has the lowest operator precedence just above comma, and its associativity is right-to-left, I suspect the only use that would break it without the extra parentheses around "x" is:

#define eval(...) __VA_ARGS__
#define m(x) do { z = x; } while (0)

m(eval(1, abc))

Which generates the following C code after preprocessing:

do { z = 1, abc; } while (0)

which ends up expanding the comma within the rvalue. But this use-case is a bit far-fetched, so I don't know if we want to require the parentheses or not.

And if we decide that we do want to require the parentheses around the "x" parameter in the "=" rvalue, then this means we have to consider whether we want to require parentheses around the macro arguments used as function/macro arguments, e.g.:

#define eval(...) __VA_ARGS__
#define m(x)    f(x)

m(eval(1, abc));

Which generates the following C code after preprocessing:

f(1, abc);

If we want to be consistent, I suspect we want to require the same for both use-cases ("=" rvalue and function/macro parameters).

Thanks,

Mathieu



--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com




[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux