From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Andreas Dilger <adilger.kernel@dilger.ca>,
Jan Kara <jack@suse.cz>, Eric Biggers <ebiggers@google.com>,
linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Subject: Re: [PATCH] ext4: avoid unused variable warning
Date: Wed, 10 Oct 2018 15:26:58 -0400 [thread overview]
Message-ID: <20181010192658.GA27646@thunk.org> (raw)
In-Reply-To: <20181010142813.1918180-1-arnd@arndb.de>
On Wed, Oct 10, 2018 at 04:27:58PM +0200, Arnd Bergmann wrote:
> The two new variables are only used in an #ifdef, so they cause a
> warning without CONFIG_QUOTA:
>
> fs/ext4/super.c: In function 'parse_options':
> fs/ext4/super.c:1977:26: error: unused variable 'grp_qf_name' [-Werror=unused-variable]
> char *p, *usr_qf_name, *grp_qf_name;
> ^~~~~~~~~~~
> fs/ext4/super.c:1977:12: error: unused variable 'usr_qf_name' [-Werror=unused-variable]
> char *p, *usr_qf_name, *grp_qf_name;
>
> Fixes: 20cefcdc2040 ("ext4: fix use-after-free race in ext4_remount()'s error path")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Hmm, I wonder if we should do something like:
#define EXT4_UNUSED_VAR __attribute__ ((unused))
and then we could do:
char *p, *usr_qf_name EXT4_UNUSED_VAR, *grp_qf_name EXT4_UNUSED_VAR;
More generally, I wonder if this is something we should have defined
for the whole kernel, as opposed to a one-off hack that ACPI and ext4
subsystems use. It's a little ugly, but I think it's much nicer than
having extra #ifdefs such as:
char *p;
#ifdef CONFIG_QUOTA
char *usr_qf_name, *grp_qf_name;
#endif
After all, the compiler is perfectly capable of ignoring variables
which are unused. And if it's only because of an #ifdef later in the
function, it would be nice to not have an extra #ifdef in the variable
declarations.
- Ted
next prev parent reply other threads:[~2018-10-11 2:50 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-10 14:27 [PATCH] ext4: avoid unused variable warning Arnd Bergmann
2018-10-10 19:26 ` Theodore Y. Ts'o [this message]
2018-10-10 19:43 ` Arnd Bergmann
2018-10-10 19:43 ` Miguel Ojeda
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181010192658.GA27646@thunk.org \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=arnd@arndb.de \
--cc=ebiggers@google.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=miguel.ojeda.sandonis@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.