* [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO
@ 2007-03-11 23:28 Rusty Russell
2007-03-12 8:23 ` Jan Beulich
2007-03-12 9:42 ` Andi Kleen
0 siblings, 2 replies; 9+ messages in thread
From: Rusty Russell @ 2007-03-11 23:28 UTC (permalink / raw)
To: lkml - Kernel Mailing List; +Cc: Andi Kleen, Jan Beulich
BUILD_BUG_ON_ZERO is named perfectly wrong, and BUILD_BUG_ON_RETURN_ZERO
is too long. Flip three bits, and the name is much more suitable.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff -r 6fb745a5bb51 include/linux/compiler-gcc.h
--- a/include/linux/compiler-gcc.h Mon Mar 12 09:12:20 2007 +1100
+++ b/include/linux/compiler-gcc.h Mon Mar 12 09:51:18 2007 +1100
@@ -24,7 +24,7 @@
/* &a[0] degrades to a pointer: a different type from an array */
#define __must_be_array(a) \
- BUILD_BUG_ON_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0])))
+ BUILD_BUG_OR_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0])))
#define inline inline __attribute__((always_inline))
#define __inline__ __inline__ __attribute__((always_inline))
diff -r 6fb745a5bb51 include/linux/kernel.h
--- a/include/linux/kernel.h Mon Mar 12 09:12:20 2007 +1100
+++ b/include/linux/kernel.h Mon Mar 12 09:51:25 2007 +1100
@@ -341,7 +341,7 @@ struct sysinfo {
result (of value 0 and type size_t), so the expression can be used
e.g. in a structure initializer (or where-ever else comma expressions
aren't permitted). */
-#define BUILD_BUG_ON_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
+#define BUILD_BUG_OR_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
/* Trap pasters of __FUNCTION__ at compile-time */
#define __FUNCTION__ (__func__)
diff -r 6fb745a5bb51 include/linux/moduleparam.h
--- a/include/linux/moduleparam.h Mon Mar 12 09:12:20 2007 +1100
+++ b/include/linux/moduleparam.h Mon Mar 12 09:51:42 2007 +1100
@@ -65,7 +65,7 @@ struct kparam_array
#define __module_param_call(prefix, name, set, get, arg, perm) \
/* Default value instead of permissions? */ \
static int __param_perm_check_##name __attribute__((unused)) = \
- BUILD_BUG_ON_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2)); \
+ BUILD_BUG_OR_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2)); \
static char __param_str_##name[] = prefix #name; \
static struct kernel_param const __param_##name \
__attribute_used__ \
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO
2007-03-11 23:28 [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO Rusty Russell
@ 2007-03-12 8:23 ` Jan Beulich
2007-03-12 8:39 ` Jan Engelhardt
2007-03-12 9:25 ` Rusty Russell
2007-03-12 9:42 ` Andi Kleen
1 sibling, 2 replies; 9+ messages in thread
From: Jan Beulich @ 2007-03-12 8:23 UTC (permalink / raw)
To: Rusty Russell; +Cc: Andi Kleen, lkml - Kernel Mailing List
I have to admit that I don't see the point here - I can't seem to make any sense of the OR... Jan
>>> Rusty Russell <rusty@rustcorp.com.au> 12.03.07 00:28 >>>
BUILD_BUG_ON_ZERO is named perfectly wrong, and BUILD_BUG_ON_RETURN_ZERO
is too long. Flip three bits, and the name is much more suitable.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff -r 6fb745a5bb51 include/linux/compiler-gcc.h
--- a/include/linux/compiler-gcc.h Mon Mar 12 09:12:20 2007 +1100
+++ b/include/linux/compiler-gcc.h Mon Mar 12 09:51:18 2007 +1100
@@ -24,7 +24,7 @@
/* &a[0] degrades to a pointer: a different type from an array */
#define __must_be_array(a) \
- BUILD_BUG_ON_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0])))
+ BUILD_BUG_OR_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0])))
#define inline inline __attribute__((always_inline))
#define __inline__ __inline__ __attribute__((always_inline))
diff -r 6fb745a5bb51 include/linux/kernel.h
--- a/include/linux/kernel.h Mon Mar 12 09:12:20 2007 +1100
+++ b/include/linux/kernel.h Mon Mar 12 09:51:25 2007 +1100
@@ -341,7 +341,7 @@ struct sysinfo {
result (of value 0 and type size_t), so the expression can be used
e.g. in a structure initializer (or where-ever else comma expressions
aren't permitted). */
-#define BUILD_BUG_ON_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
+#define BUILD_BUG_OR_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
/* Trap pasters of __FUNCTION__ at compile-time */
#define __FUNCTION__ (__func__)
diff -r 6fb745a5bb51 include/linux/moduleparam.h
--- a/include/linux/moduleparam.h Mon Mar 12 09:12:20 2007 +1100
+++ b/include/linux/moduleparam.h Mon Mar 12 09:51:42 2007 +1100
@@ -65,7 +65,7 @@ struct kparam_array
#define __module_param_call(prefix, name, set, get, arg, perm) \
/* Default value instead of permissions? */ \
static int __param_perm_check_##name __attribute__((unused)) = \
- BUILD_BUG_ON_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2)); \
+ BUILD_BUG_OR_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2)); \
static char __param_str_##name[] = prefix #name; \
static struct kernel_param const __param_##name \
__attribute_used__ \
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO
2007-03-12 8:23 ` Jan Beulich
@ 2007-03-12 8:39 ` Jan Engelhardt
2007-03-12 9:25 ` Rusty Russell
1 sibling, 0 replies; 9+ messages in thread
From: Jan Engelhardt @ 2007-03-12 8:39 UTC (permalink / raw)
To: Jan Beulich; +Cc: Rusty Russell, Andi Kleen, lkml - Kernel Mailing List
On Mar 12 2007 08:23, Jan Beulich wrote:
>
>I have to admit that I don't see the point here - I can't seem to make any
>sense of the OR... Jan
BUILD_BUG_OR_ZERO will either (a) result in a build bug or (b) the number
zero, suitable for arithmetic.
>>>> Rusty Russell <rusty@rustcorp.com.au> 12.03.07 00:28 >>>
>BUILD_BUG_ON_ZERO is named perfectly wrong, and BUILD_BUG_ON_RETURN_ZERO
>is too long. Flip three bits, and the name is much more suitable.
>
>Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
>diff -r 6fb745a5bb51 include/linux/compiler-gcc.h
>--- a/include/linux/compiler-gcc.h Mon Mar 12 09:12:20 2007 +1100
>+++ b/include/linux/compiler-gcc.h Mon Mar 12 09:51:18 2007 +1100
>@@ -24,7 +24,7 @@
>
> /* &a[0] degrades to a pointer: a different type from an array */
> #define __must_be_array(a) \
>- BUILD_BUG_ON_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0])))
>+ BUILD_BUG_OR_ZERO(__builtin_types_compatible_p(typeof(a), typeof(&a[0])))
>
> #define inline inline __attribute__((always_inline))
> #define __inline__ __inline__ __attribute__((always_inline))
>diff -r 6fb745a5bb51 include/linux/kernel.h
>--- a/include/linux/kernel.h Mon Mar 12 09:12:20 2007 +1100
>+++ b/include/linux/kernel.h Mon Mar 12 09:51:25 2007 +1100
>@@ -341,7 +341,7 @@ struct sysinfo {
> result (of value 0 and type size_t), so the expression can be used
> e.g. in a structure initializer (or where-ever else comma expressions
> aren't permitted). */
>-#define BUILD_BUG_ON_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
>+#define BUILD_BUG_OR_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
>
> /* Trap pasters of __FUNCTION__ at compile-time */
> #define __FUNCTION__ (__func__)
>diff -r 6fb745a5bb51 include/linux/moduleparam.h
>--- a/include/linux/moduleparam.h Mon Mar 12 09:12:20 2007 +1100
>+++ b/include/linux/moduleparam.h Mon Mar 12 09:51:42 2007 +1100
>@@ -65,7 +65,7 @@ struct kparam_array
> #define __module_param_call(prefix, name, set, get, arg, perm) \
> /* Default value instead of permissions? */ \
> static int __param_perm_check_##name __attribute__((unused)) = \
>- BUILD_BUG_ON_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2)); \
>+ BUILD_BUG_OR_ZERO((perm) < 0 || (perm) > 0777 || ((perm) & 2)); \
> static char __param_str_##name[] = prefix #name; \
> static struct kernel_param const __param_##name \
> __attribute_used__ \
>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
Jan
--
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO
2007-03-12 8:23 ` Jan Beulich
2007-03-12 8:39 ` Jan Engelhardt
@ 2007-03-12 9:25 ` Rusty Russell
2007-03-12 11:41 ` Stefan Richter
1 sibling, 1 reply; 9+ messages in thread
From: Rusty Russell @ 2007-03-12 9:25 UTC (permalink / raw)
To: Jan Beulich; +Cc: Andi Kleen, lkml - Kernel Mailing List
On Mon, 2007-03-12 at 08:23 +0000, Jan Beulich wrote:
> I have to admit that I don't see the point here - I can't seem to make
> any sense of the OR... Jan
At least one other person thought that:
#define BUILD_BUG_ON_ZERO(e) BUILD_BUG_ON((e) == 0)
OTOH, BUILD_BUG_OR_ZERO says what happens: either it's a build bug, or
it's zero.
Hope that clarifies,
Rusty.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO
2007-03-11 23:28 [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO Rusty Russell
2007-03-12 8:23 ` Jan Beulich
@ 2007-03-12 9:42 ` Andi Kleen
1 sibling, 0 replies; 9+ messages in thread
From: Andi Kleen @ 2007-03-12 9:42 UTC (permalink / raw)
To: Rusty Russell; +Cc: lkml - Kernel Mailing List, Jan Beulich
On Mon, Mar 12, 2007 at 10:28:13AM +1100, Rusty Russell wrote:
> BUILD_BUG_ON_ZERO is named perfectly wrong, and BUILD_BUG_ON_RETURN_ZERO
> is too long. Flip three bits, and the name is much more suitable.
Ok for me.
-Andi
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO
2007-03-12 9:25 ` Rusty Russell
@ 2007-03-12 11:41 ` Stefan Richter
2007-03-12 11:49 ` Robert P. J. Day
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Richter @ 2007-03-12 11:41 UTC (permalink / raw)
To: Rusty Russell; +Cc: Jan Beulich, Andi Kleen, linux-kernel
Rusty Russell wrote:
> On Mon, 2007-03-12 at 08:23 +0000, Jan Beulich wrote:
>> I have to admit that I don't see the point here - I can't seem to make
>> any sense of the OR... Jan
>
> At least one other person thought that:
>
> #define BUILD_BUG_ON_ZERO(e) BUILD_BUG_ON((e) == 0)
>
> OTOH, BUILD_BUG_OR_ZERO says what happens: either it's a build bug, or
> it's zero.
What about ZERO_UNLESS_BUILD_BUG_ON(e)? It's long though...
--
Stefan Richter
-=====-=-=== --== -==--
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO
2007-03-12 11:41 ` Stefan Richter
@ 2007-03-12 11:49 ` Robert P. J. Day
2007-03-12 14:14 ` Stefan Richter
0 siblings, 1 reply; 9+ messages in thread
From: Robert P. J. Day @ 2007-03-12 11:49 UTC (permalink / raw)
To: Stefan Richter; +Cc: Rusty Russell, Jan Beulich, Andi Kleen, linux-kernel
On Mon, 12 Mar 2007, Stefan Richter wrote:
> Rusty Russell wrote:
> > On Mon, 2007-03-12 at 08:23 +0000, Jan Beulich wrote:
> >> I have to admit that I don't see the point here - I can't seem to make
> >> any sense of the OR... Jan
> >
> > At least one other person thought that:
> >
> > #define BUILD_BUG_ON_ZERO(e) BUILD_BUG_ON((e) == 0)
> >
> > OTOH, BUILD_BUG_OR_ZERO says what happens: either it's a build bug, or
> > it's zero.
>
> What about ZERO_UNLESS_BUILD_BUG_ON(e)? It's long though...
how often is this going to be used? it's not like the tree is
currently awash in calls to BUILD_BUG_ON_ZERO as it is.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO
2007-03-12 11:49 ` Robert P. J. Day
@ 2007-03-12 14:14 ` Stefan Richter
2007-03-12 22:25 ` Rusty Russell
0 siblings, 1 reply; 9+ messages in thread
From: Stefan Richter @ 2007-03-12 14:14 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: Rusty Russell, Jan Beulich, Andi Kleen, linux-kernel
Robert P. J. Day wrote:
> On Mon, 12 Mar 2007, Stefan Richter wrote:
>> Rusty Russell wrote:
>> > OTOH, BUILD_BUG_OR_ZERO says what happens: either it's a build bug, or
>> > it's zero.
>>
>> What about ZERO_UNLESS_BUILD_BUG_ON(e)? It's long though...
>
> how often is this going to be used? it's not like the tree is
> currently awash in calls to BUILD_BUG_ON_ZERO as it is.
Most of the time it will hidden as a macro-in-a-macro, like in
ARRAY_SIZE(). So the length of the name doesn't matter much. But then,
the _name_ itself doesn't matter much because authors of public macros
are the primary user group, not John Driverhacker.
--
Stefan Richter
-=====-=-=== --== -==--
http://arcgraph.de/sr/
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO
2007-03-12 14:14 ` Stefan Richter
@ 2007-03-12 22:25 ` Rusty Russell
0 siblings, 0 replies; 9+ messages in thread
From: Rusty Russell @ 2007-03-12 22:25 UTC (permalink / raw)
To: Stefan Richter; +Cc: Robert P. J. Day, Jan Beulich, Andi Kleen, linux-kernel
On Mon, 2007-03-12 at 15:14 +0100, Stefan Richter wrote:
> Robert P. J. Day wrote:
> > On Mon, 12 Mar 2007, Stefan Richter wrote:
> >> Rusty Russell wrote:
> >> > OTOH, BUILD_BUG_OR_ZERO says what happens: either it's a build bug, or
> >> > it's zero.
> >>
> >> What about ZERO_UNLESS_BUILD_BUG_ON(e)? It's long though...
> >
> > how often is this going to be used? it's not like the tree is
> > currently awash in calls to BUILD_BUG_ON_ZERO as it is.
>
> Most of the time it will hidden as a macro-in-a-macro, like in
> ARRAY_SIZE(). So the length of the name doesn't matter much. But then,
> the _name_ itself doesn't matter much because authors of public macros
> are the primary user group, not John Driverhacker.
Well, there's a four line comment above it, so *someone* thought it
worth documenting. Even if the new name isn't great, the old name is
actively misleading. That's a 13, and we could be a 4.
http://ozlabs.org/~rusty/ols-2003-keynote/img52.html
Cheers,
Rusty.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-03-12 22:26 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-11 23:28 [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO Rusty Russell
2007-03-12 8:23 ` Jan Beulich
2007-03-12 8:39 ` Jan Engelhardt
2007-03-12 9:25 ` Rusty Russell
2007-03-12 11:41 ` Stefan Richter
2007-03-12 11:49 ` Robert P. J. Day
2007-03-12 14:14 ` Stefan Richter
2007-03-12 22:25 ` Rusty Russell
2007-03-12 9:42 ` Andi Kleen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).