[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+C-WL9ARNvOqeA4n5Abnja+99O4F1VdMDUPjuRCcXiVsMTc7A@mail.gmail.com>
Date: Wed, 12 Feb 2014 23:03:03 -0500
From: Patrick Palka <patrick@...cs.ath.cx>
To: Joe Perches <joe@...ches.com>
Cc: linux-kernel@...r.kernel.org, "Theodore Ts'o" <tytso@....edu>,
adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org
Subject: Re: [PATCH] ext4: address a benign compiler warning
On Wed, Feb 12, 2014 at 9:59 PM, Joe Perches <joe@...ches.com> wrote:
> On Wed, 2014-02-12 at 21:13 -0500, Patrick Palka wrote:
>> When !defined(CONFIG_EXT4_DEBUG), mb_debug() should be defined as an
>> empty do-while statement so as to suppress the following compiler
>> warning:
>
> Hello Patrick.
>
>> fs/ext4/mballoc.c: In function 'ext4_mb_cleanup_pa':
>> fs/ext4/mballoc.c:2659:47: warning: suggest braces around empty body in an 'if' statement [-Wempty-body]
>> mb_debug(1, "mballoc: %u PAs left\n", count);
>> ---
>> diff --git a/fs/ext4/mballoc.h b/fs/ext4/mballoc.h
> []
>> @@ -48,7 +48,7 @@ extern ushort ext4_mballoc_debug;
>> } \
>> } while (0)
>> #else
>> -#define mb_debug(n, fmt, a...)
>> +#define mb_debug(n, fmt, a...) do { } while (0)
>
> Ideally, this section should be something like below
> so the !CONFIG_EXT4_DEBUG case still verifies that
> the format and argument types match.
>
> This can help avoid people adding debug statements but
> not compiling with the proper CONFIG_<foo> variable set.
>
> ---
>
> #ifdef CONFIG_EXT4_DEBUG
> extern ushort ext4_mballoc_debug;
>
> #define mb_debug(n, fmt, ...) \
> do { \
> if ((n) <= ext4_mballoc_debug) \
> pr_debug(fmt, ##__VA_ARGS__); \
> } \
> } while (0)
> #else
> #define mb_debug(n, fmt, ...) \
> no_printk(KERN_DEBUG fmt, ##__VA_ARGS__)
> #endif
>
>
Hi Joe,
Thanks! I was not aware of that idiom. It makes a good amount of
sense. I'm going to send a revised version of the patch shortly.
Patrick
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists