[PATCH] fix ASSERT and ASSERT_ALWAYS

[PATCH] fix ASSERT and ASSERT_ALWAYS

[Christoph Hellwig]

 - remove the != 0 inside the unlikely in ASSERT_ALWAYS because sparse now
   complains about comparisms between pointers and 0
 - add a standalone ASSERT implementation because defining it to
   ASSERT_ALWAYS means the string is expanded before the #token passing
   stringification.  This way we get the actual content of the
   assertatio in the assfail message and don't overflow sparse's
   strinification buffer leading to sparse error messages.


Signed-off-by: Christoph Hellwig <hch@lst.de>

Index: linux-2.6-xfs/fs/xfs/support/debug.h
===================================================================
--- linux-2.6-xfs.orig/fs/xfs/support/debug.h	2007-07-14 15:55:12.000000000 +0200
+++ linux-2.6-xfs/fs/xfs/support/debug.h	2007-07-14 15:55:46.000000000 +0200
@@ -34,10 +34,10 @@ extern void cmn_err(int, char *, ...)
 extern void assfail(char *expr, char *f, int l);
 
 #define ASSERT_ALWAYS(expr)	\
-	(unlikely((expr) != 0) ? (void)0 : assfail(#expr, __FILE__, __LINE__))
+	(unlikely(expr) ? (void)0 : assfail(#expr, __FILE__, __LINE__))
 
 #ifndef DEBUG
-# define ASSERT(expr)	((void)0)
+#define ASSERT(expr)	((void)0)
 
 #ifndef STATIC
 # define STATIC static noinline
@@ -49,8 +49,10 @@ extern void assfail(char *expr, char *f,
 
 #else /* DEBUG */
 
-# define ASSERT(expr)	ASSERT_ALWAYS(expr)
-# include <linux/random.h>
+#include <linux/random.h>
+
+#define ASSERT(expr)	\
+	(unlikely(expr) ? (void)0 : assfail(#expr, __FILE__, __LINE__))
 
 #ifndef STATIC
 # define STATIC noinline

Re: [PATCH] fix ASSERT and ASSERT_ALWAYS

[Eric Sandeen]

Christoph Hellwig wrote:
>  - remove the != 0 inside the unlikely in ASSERT_ALWAYS because sparse now
>    complains about comparisms between pointers and 0
>  - add a standalone ASSERT implementation because defining it to
>    ASSERT_ALWAYS means the string is expanded before the #token passing
>    stringification.  This way we get the actual content of the
>    assertatio in the assfail message and don't overflow sparse's
>    strinification buffer leading to sparse error messages.

Looks fine to me.

-Eric

> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> Index: linux-2.6-xfs/fs/xfs/support/debug.h
> ===================================================================
> --- linux-2.6-xfs.orig/fs/xfs/support/debug.h	2007-07-14 15:55:12.000000000 +0200
> +++ linux-2.6-xfs/fs/xfs/support/debug.h	2007-07-14 15:55:46.000000000 +0200
> @@ -34,10 +34,10 @@ extern void cmn_err(int, char *, ...)
>  extern void assfail(char *expr, char *f, int l);
>  
>  #define ASSERT_ALWAYS(expr)	\
> -	(unlikely((expr) != 0) ? (void)0 : assfail(#expr, __FILE__, __LINE__))
> +	(unlikely(expr) ? (void)0 : assfail(#expr, __FILE__, __LINE__))
>  
>  #ifndef DEBUG
> -# define ASSERT(expr)	((void)0)
> +#define ASSERT(expr)	((void)0)
>  
>  #ifndef STATIC
>  # define STATIC static noinline
> @@ -49,8 +49,10 @@ extern void assfail(char *expr, char *f,
>  
>  #else /* DEBUG */
>  
> -# define ASSERT(expr)	ASSERT_ALWAYS(expr)
> -# include <linux/random.h>
> +#include <linux/random.h>
> +
> +#define ASSERT(expr)	\
> +	(unlikely(expr) ? (void)0 : assfail(#expr, __FILE__, __LINE__))
>  
>  #ifndef STATIC
>  # define STATIC noinline
> 
> 

Re: [PATCH] fix ASSERT and ASSERT_ALWAYS

[David Chinner]

On Sat, Jul 14, 2007 at 06:04:21PM +0200, Christoph Hellwig wrote:
>  - remove the != 0 inside the unlikely in ASSERT_ALWAYS because sparse now
>    complains about comparisms between pointers and 0
>  - add a standalone ASSERT implementation because defining it to
>    ASSERT_ALWAYS means the string is expanded before the #token passing
>    stringification.  This way we get the actual content of the
>    assertatio in the assfail message and don't overflow sparse's
>    strinification buffer leading to sparse error messages.
> 
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

OK.

Rather than replying to each patch, Christoph - I've taken the
whole set into my queue for 2.6.24. All the warnings and cleanups
look ok and should not be a problem, but I need to have a much
closer look at the bmbt_rec endian notation series before that
goes further.

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group