Message ID | 20241203-is_constexpr-refactor-v1-1-4e4cbaecc216@wanadoo.fr (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | compiler.h: refactor __is_constexpr() into is_const{,_true,_false}() | expand |
On Thu. 5 Dec 2024 at 03:30, David Laight <David.Laight@aculab.com> wrote: > From: Vincent Mailhol > > Sent: 02 December 2024 17:33 > > > > From: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > > > > For completion, add statically_false() which is the equivalent of > > statically_true() except that it will return true only if the input is > > known to be false at compile time. > > This is pretty much pointless. > It is just as easy to invert the condition at the call site. To start with, I will argue that: statically_false(foo) is more pretty than statically_true(!(foo)) In addition, the simple negation !(foo) only works if foo is a boolean. If it is an integer, you would get the -Wint-in-bool-context warning. Thus you would have to write: statically_true((foo) == 0) Anyone using this in a global header basically does not know what type of argument they are getting. So, the (foo) == 0 trick is a must. But because it is ugly, better to encapsulate it once for all. The statically_false() is just cleaner and less error prone. That said, I am not strongly opposed to removing statically_false(), but in that case, I would also remove is_const_false(). For me, these come as a pair, either we have both or we have none. Only having one of these looked unbalanced. Yours sincerely, Vincent Mailhol
From: Vincent Mailhol > Sent: 05 December 2024 15:26 > > On Thu. 5 Dec 2024 at 03:30, David Laight <David.Laight@aculab.com> wrote: > > From: Vincent Mailhol > > > Sent: 02 December 2024 17:33 > > > > > > From: Vincent Mailhol <mailhol.vincent@wanadoo.fr> > > > > > > For completion, add statically_false() which is the equivalent of > > > statically_true() except that it will return true only if the input is > > > known to be false at compile time. > > > > This is pretty much pointless. > > It is just as easy to invert the condition at the call site. > > To start with, I will argue that: > > statically_false(foo) > > is more pretty than > > statically_true(!(foo)) Except that the test is more likely to be: statically_false(x > y) and the invert is then statically_true(x <= y) No different from C itself, there is no 'ifnot (condition) {...}' (don't talk to me about perl...) I suspect you need to pretty much remove all the comments that cross-refer to statically_true() from the other patches. So is_const_true() is just 'return true if the expression is a 'non-zero constant integer expression'. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
diff --git a/include/linux/compiler.h b/include/linux/compiler.h index 469a64dd6495fefab2c85ffc279568a657b72660..a2a56a50dd85227a4fdc62236a2710ca37c5ba52 100644 --- a/include/linux/compiler.h +++ b/include/linux/compiler.h @@ -314,6 +314,7 @@ static inline void *offset_to_ptr(const int *off) * values to determine that the condition is statically true. */ #define statically_true(x) (__builtin_constant_p(x) && (x)) +#define statically_false(x) (__builtin_constant_p(x) && (x) == 0) /* * This is needed in functions which generate the stack canary, see