From: Dan Carpenter <dan.carpenter@oracle.com>
To: Harshvardhan Jha <harshvardhan.jha@oracle.com>
Cc: smatch@vger.kernel.org
Subject: Re: [PATCH 2/2] [PATCH 2/2] Fix handle_bit_test so that null set condition is taken care of
Date: Mon, 12 Jul 2021 16:57:54 +0300 [thread overview]
Message-ID: <20210712135754.GI1931@kadam> (raw)
In-Reply-To: <20210712125428.30186-2-harshvardhan.jha@oracle.com>
On Mon, Jul 12, 2021 at 06:24:28PM +0530, Harshvardhan Jha wrote:
> ---
> smatch_extra.c | 17 +++++++++--------
> validation/sm_bits2.c | 28 ++++++++++++++++++++++++++++
> 2 files changed, 37 insertions(+), 8 deletions(-)
> create mode 100644 validation/sm_bits2.c
>
> diff --git a/smatch_extra.c b/smatch_extra.c
> index e864646a..27bf5a02 100644
> --- a/smatch_extra.c
> +++ b/smatch_extra.c
> @@ -2061,7 +2061,7 @@ static void match_comparison(struct expression *expr)
>
> static bool handle_bit_test(struct expression *expr)
> {
> - struct range_list *orig_rl, *rl;
> + struct range_list *orig_rl, *rl, *true_rl, *false_rl;
> struct expression *shift, *mask, *var;
> struct bit_info *bit_info;
> sval_t sval;
> @@ -2083,23 +2083,24 @@ static bool handle_bit_test(struct expression *expr)
> bit_info = get_bit_info(mask);
> if (!bit_info)
> return false;
> - if (!bit_info->possible)
> + if (!bit_info->possible){
> + set_true_false_states_expr(my_id, var, alloc_estate_empty(), NULL);
> return false;
> + }
>
> get_absolute_rl(var, &orig_rl);
> if (sval_is_negative(rl_min(orig_rl)) ||
> rl_max(orig_rl).uvalue > type_bits(get_type(shift->left)))
> return false;
>
> - low.value = ffsll(bit_info->possible);
> - high.value = sm_fls64(bit_info->possible);
> + low.value = ffsll(bit_info->possible) - 1;
> + high.value = sm_fls64(bit_info->possible) - 1;
> rl = alloc_rl(low, high);
> rl = cast_rl(get_type(var), rl);
> - rl = rl_intersection(orig_rl, rl);
> - if (!rl)
> - return false;
> + true_rl = rl_intersection(orig_rl, rl);
> + false_rl = rl_filter(orig_rl, rl);
The false_rl isn't correct. For the false_side we should use
bit_info->set instead of bit_info->possible. It doesn't matter in the
test code because the value of mask is known so the possibly set and
the definitely set are the same.
In other words there can be some overlap between the potential values
on the true path and the false path.
regards,
dan carpenter
next prev parent reply other threads:[~2021-07-12 14:01 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-12 12:54 [PATCH 1/2] extra: Fix false output of handle_AND_op and handle_AND_condition Harshvardhan Jha
2021-07-12 12:54 ` [PATCH 2/2] [PATCH 2/2] Fix handle_bit_test so that null set condition is taken care of Harshvardhan Jha
2021-07-12 13:57 ` Dan Carpenter [this message]
2021-07-12 13:00 ` [PATCH 1/2] extra: Fix false output of handle_AND_op and handle_AND_condition Dan Carpenter
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=20210712135754.GI1931@kadam \
--to=dan.carpenter@oracle.com \
--cc=harshvardhan.jha@oracle.com \
--cc=smatch@vger.kernel.org \
/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 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).