On Tuesday 09 of March 2010 21:11:57 Pavel Roskin wrote:
> Ironically, the fix for :? may benefit from that operator:
>
> do_warn_for_enum_conversions(expr->cond_true ?: expr->conditional, type);
Yeah, that's exactly what I've tried ;-)
> do_warn_for_enum_conversions(expr->cond_false ?: expr->conditional, type);
Does it mean the cond_false may be also omitted? I can't image how the enum
conversion analysis can be useful in that case. I've ensured the optional
analysis would no more crash on another corner case in the first place:
--- a/evaluate.c
+++ b/evaluate.c
@@ -327,13 +327,35 @@ warn_for_int_to_enum_conversion (struct expression
*expr, struct symbol *typeb)
}
static void
-warn_for_enum_conversions(struct expression *expr, struct symbol *type)
+do_warn_for_enum_conversions(struct expression *expr, struct symbol *type)
{
+ if (!expr || !type)
+ /* do not crash when there is nothing to check */
+ return;
+
warn_for_different_enum_types (expr, type);
warn_for_enum_to_int_conversion (expr, type);
warn_for_int_to_enum_conversion (expr, type);
}
> At least I was able to run sparse on the whole kernel (wireless-testing,
> which is based on 2.6.34-rc1) without crashing or reporting anything
> strange.
>
> Actually, omitting the false conditional appears to be invalid.
Unfortunately it's not that easy. I am still getting a non-sense warning for:
static void foo(void)
{
enum { VAL } y, x = VAL;
y = x ?: VAL;
}
$ ./sparse enum.c
enum.c:4:9: warning: conversion of
enum.c:4:9: int to
enum.c:4:9: int enum <noident>
I need to somehow get over the EXPR_IMPLIED_CAST to dig the original enum_type
from there...
Kamil
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
