public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/65864] New: Consider emitting -Wswitch-bool less aggressively?
@ 2015-04-23 17:19 ktkachov at gcc dot gnu.org
2015-04-23 17:23 ` [Bug c/65864] " mpolacek at gcc dot gnu.org
2015-04-27 10:03 ` ktkachov at gcc dot gnu.org
0 siblings, 2 replies; 3+ messages in thread
From: ktkachov at gcc dot gnu.org @ 2015-04-23 17:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65864
Bug ID: 65864
Summary: Consider emitting -Wswitch-bool less aggressively?
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org
Consider the following function from the linux kernel (fs/nfs/nfs4proc.c):
int nfs4_proc_get_rootfh(struct nfs_server *server, struct nfs_fh *fhandle,
struct nfs_fsinfo *info,
bool auth_probe)
{
int status;
switch (auth_probe) {
case false:
status = nfs4_lookup_root(server, fhandle, info);
if (status != -NFS4ERR_WRONGSEC)
break;
default:
status = nfs4_do_find_root_sec(server, fhandle, info);
}
if (status == 0)
status = nfs4_server_capabilities(server, fhandle);
if (status == 0)
status = nfs4_do_fsinfo(server, fhandle, info);
return nfs4_map_errors(status);
}
The kernel guys have reported that the new -Wswitch-bool warns on this code
and, while ugly, it was a deliberate decision to write it that way (they make
'creative' use of the fall-through in the switch).
I wonder whether it makes sense to restrict the -Wswitch-bool warning to the
cases where the switch condition becomes a boolean from a complex expression
(i.e. a && 0xff, instead of the probably intended a & 0xff) and not warn when
the switch variable is a simple boolean var.
what do you think?
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c/65864] Consider emitting -Wswitch-bool less aggressively?
2015-04-23 17:19 [Bug c/65864] New: Consider emitting -Wswitch-bool less aggressively? ktkachov at gcc dot gnu.org
@ 2015-04-23 17:23 ` mpolacek at gcc dot gnu.org
2015-04-27 10:03 ` ktkachov at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2015-04-23 17:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65864
--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I think they should simply cast the controlling expression to int--that should
quash the warning. Does this workaround sound reasonable to them?
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Bug c/65864] Consider emitting -Wswitch-bool less aggressively?
2015-04-23 17:19 [Bug c/65864] New: Consider emitting -Wswitch-bool less aggressively? ktkachov at gcc dot gnu.org
2015-04-23 17:23 ` [Bug c/65864] " mpolacek at gcc dot gnu.org
@ 2015-04-27 10:03 ` ktkachov at gcc dot gnu.org
1 sibling, 0 replies; 3+ messages in thread
From: ktkachov at gcc dot gnu.org @ 2015-04-27 10:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65864
ktkachov at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from ktkachov at gcc dot gnu.org ---
Turns out the kernel guys were not against rewriting the
switch statement to an if-else.
https://lkml.org/lkml/2015/4/23/367
Closing this out then
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-04-27 10:03 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-04-23 17:19 [Bug c/65864] New: Consider emitting -Wswitch-bool less aggressively? ktkachov at gcc dot gnu.org
2015-04-23 17:23 ` [Bug c/65864] " mpolacek at gcc dot gnu.org
2015-04-27 10:03 ` ktkachov at gcc dot gnu.org
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 read-only IMAP folder(s) and NNTP newsgroup(s).