[PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO

[PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO

[Rusty Russell]

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__						\

Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO

[Jan Beulich]

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__						\

Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO

[Jan Engelhardt]

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
-- 

Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO

[Rusty Russell]

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.

Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO

[Stefan Richter]

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/

Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO

[Robert P. J. Day]

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
========================================================================

Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO

[Stefan Richter]

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/

Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO

[Rusty Russell]

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.

Re: [PATCH] BUILD_BUG_ON_ZERO -> BUILD_BUG_OR_ZERO

[Andi Kleen]

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