[PATCH] fix pointer casts in evaluate_compare()

[PATCH] fix pointer casts in evaluate_compare()

[Xi Wang]

The results of cast_to() seem unused.  Assign them to expr->left and
expr->right.

Signed-off-by: Xi Wang <xi.wang@gmail.com>
---
 evaluate.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/evaluate.c b/evaluate.c
index 0dfa519..d9c767f 100644
--- a/evaluate.c
+++ b/evaluate.c
@@ -1024,11 +1024,11 @@ static struct symbol *evaluate_compare(struct expression *expr)
 			goto OK;
 		}
 		if (is_null1 && (rclass & TYPE_PTR)) {
-			left = cast_to(left, rtype);
+			expr->left = cast_to(left, rtype);
 			goto OK;
 		}
 		if (is_null2 && (lclass & TYPE_PTR)) {
-			right = cast_to(right, ltype);
+			expr->right = cast_to(right, ltype);
 			goto OK;
 		}
 	}
@@ -1044,11 +1044,11 @@ static struct symbol *evaluate_compare(struct expression *expr)
 	if (expr->op == SPECIAL_EQUAL || expr->op == SPECIAL_NOTEQUAL) {
 		if (ltype->ctype.as == rtype->ctype.as) {
 			if (lbase == &void_ctype) {
-				right = cast_to(right, ltype);
+				expr->right = cast_to(right, ltype);
 				goto OK;
 			}
 			if (rbase == &void_ctype) {
-				left = cast_to(left, rtype);
+				expr->left = cast_to(left, rtype);
 				goto OK;
 			}
 		}
-- 
1.8.1.2

Re: [PATCH] fix pointer casts in evaluate_compare()

[Pekka Enberg]

On Thu, May 16, 2013 at 11:55 PM, Xi Wang <xi.wang@gmail.com> wrote:
> The results of cast_to() seem unused.  Assign them to expr->left and
> expr->right.
>
> Signed-off-by: Xi Wang <xi.wang@gmail.com>

How did you find about this? Is this needed to fix a reproducible issue?

> ---
>  evaluate.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/evaluate.c b/evaluate.c
> index 0dfa519..d9c767f 100644
> --- a/evaluate.c
> +++ b/evaluate.c
> @@ -1024,11 +1024,11 @@ static struct symbol *evaluate_compare(struct expression *expr)
>                         goto OK;
>                 }
>                 if (is_null1 && (rclass & TYPE_PTR)) {
> -                       left = cast_to(left, rtype);
> +                       expr->left = cast_to(left, rtype);
>                         goto OK;
>                 }
>                 if (is_null2 && (lclass & TYPE_PTR)) {
> -                       right = cast_to(right, ltype);
> +                       expr->right = cast_to(right, ltype);
>                         goto OK;
>                 }
>         }
> @@ -1044,11 +1044,11 @@ static struct symbol *evaluate_compare(struct expression *expr)
>         if (expr->op == SPECIAL_EQUAL || expr->op == SPECIAL_NOTEQUAL) {
>                 if (ltype->ctype.as == rtype->ctype.as) {
>                         if (lbase == &void_ctype) {
> -                               right = cast_to(right, ltype);
> +                               expr->right = cast_to(right, ltype);
>                                 goto OK;
>                         }
>                         if (rbase == &void_ctype) {
> -                               left = cast_to(left, rtype);
> +                               expr->left = cast_to(left, rtype);
>                                 goto OK;
>                         }
>                 }
> --
> 1.8.1.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] fix pointer casts in evaluate_compare()

[Xi Wang]

On Sun, May 19, 2013 at 3:48 AM, Pekka Enberg <penberg@kernel.org> wrote:
> How did you find about this? Is this needed to fix a reproducible issue?

I was debugging like (p == 0) and noticed that sparse lost this cast
to pointers.

A more serious problem in evaluate_compare() is that sparse evaluates
comparisons to bool, which should have been int, according to the C
standard.

For example, sparse incorrectly evaluates sizeof(1 == 0) to 1, while
gcc and clang evaluate this to 4 (i.e., sizeof(int)).

Similar problems exist when sparse evaluates other conditional
expressions, such as !, &&, ||.

This also confuses sparse-llvm.  For example, given OP_AND_BOOL x, y,
should sparse-llvm assume that x and y can be int, bool, or some other
type?

- xi