WARN_ON() which sometimes sucks
From: Alexey Dobriyan
Date: Tue Jul 31 2007 - 11:56:21 EST
It started when I tried to write
WARN_ON(m->seq_ops_allocated);
in today's "[PATCH] single_open/seq_release leak diagnostics¹.
Suprisingly compiler told me piss off with:
CC fs/seq_file.o
fs/seq_file.c: In function 'seq_release':
fs/seq_file.c:285: error: 'typeof' applied to a bit-field
Well, duh! Earlier versions of WARN_ON allowed that until commit
684f978347deb42d180373ac4c427f82ef963171² which added typeof().
OK, nobody noticed that WARN_ON(bitfield) stopped working. But I
question the rationale of that commit:
Letting WARN_ON/WARN_ON_ONCE return the condition means that you could
do
if (WARN_ON(blah)) {
handle_impossible_case
}
Rather than
if (unlikely(blah)) {
WARN_ON(1)
handle_impossible_case
}
I think that second case is more clear and immediately understandable.
If folks agree, I'll send revert so that WARN_ON(var), WARN_ON(ptr),
WARN_ON(bitfield) and WARN_ON(condition) work as expected.
¹ http://marc.info/?l=linux-kernel&m=118588389612083&w=2
²
tree db9025d8c6b267565c7110e09b16193957186a48
parent 6299a2dec89d22940e36832f15c0addfb77e6910
author Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> 1159520346 -0700
committer Linus Torvalds <torvalds@xxxxxxxxxxx> 1159546686 -0700
[PATCH] Let WARN_ON/WARN_ON_ONCE return the condition
Letting WARN_ON/WARN_ON_ONCE return the condition means that you could do
if (WARN_ON(blah)) {
handle_impossible_case
}
Rather than
if (unlikely(blah)) {
WARN_ON(1)
handle_impossible_case
}
I checked all the newly added WARN_ON_ONCE users and none of them test the
return status so we can still change it.
[akpm@xxxxxxxx: warning fix]
[akpm@xxxxxxxx: build fix]
Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxx>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/