From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:14704 "EHLO mx0a-00069f02.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230458AbhGLNCr (ORCPT ); Mon, 12 Jul 2021 09:02:47 -0400 Received: from pps.filterd (m0246629.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16CCpHlt000795 for ; Mon, 12 Jul 2021 12:59:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : from : to : cc : subject : message-id : references : content-type : in-reply-to : mime-version; s=corp-2020-01-29; bh=VptjZc84bcSUBg816LtGwShqNPd/J3/8BLO38hlzeKM=; b=MjI1IIoMVzvDfbvWq5dUpcp6d0hDjg+dLtJTpo3oCvDC34aOkpb1e78tCAc6a37oAMg1 mNkXdwP9Ib9BMh6LtOB5YifyrLzELJJhWbx3u3KVT3fmpY1M+ZjQ0DvA25S8KzcShaQr 0dna0jLJ3jHlQM5bc8IyTnhJ4HnForvdunL9+bntKZ5wwU1GERThatbvp2n7LKBB9QUZ jAcVNI6YMkcWTjIry3I1Ld+ufJa9i/1zv5aCKD0vlW+DtbowxWQLml1ZjMf/x0chMKRK p7kymRLckmc+ZDoctTwFeXKycU6M/YMqy3F6EnuAk7J35BuRwF7qglaKBoJVyS6SPdbD Ag== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by mx0b-00069f02.pphosted.com with ESMTP id 39q3eajkpv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 12 Jul 2021 12:59:59 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 16CConvQ046330 for ; Mon, 12 Jul 2021 12:59:58 GMT Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2175.outbound.protection.outlook.com [104.47.55.175]) by aserp3030.oracle.com with ESMTP id 39qycrjxus-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 12 Jul 2021 12:59:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VptjZc84bcSUBg816LtGwShqNPd/J3/8BLO38hlzeKM=; b=P1+1WXhMeM64etRRYtCuhE4kBOC3uRsEUkrRwHP0CmyUrGlGk0wCHWeWcyvjULe5vPsf7IHxa7Id4WfrgiIQq5Xjqxije+xvxqeU+n+7cdxPP5MKQ1pWJ9MKaXxfJYjF9uVXNlYcES+3ymBm/Unm0hyTfAwsiYu7MrOT9yEIoXM= Date: Mon, 12 Jul 2021 15:59:38 +0300 From: Dan Carpenter Subject: Re: [PATCH 2/2] Fix handle_bit_test so that null set condition is taken care of Message-ID: <20210712125938.GG1931@kadam> References: <20210712123947.24116-1-harshvardhan.jha@oracle.com> <20210712123947.24116-2-harshvardhan.jha@oracle.com> Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210712123947.24116-2-harshvardhan.jha@oracle.com> MIME-Version: 1.0 List-ID: To: Harshvardhan Jha Cc: smatch@vger.kernel.org On Mon, Jul 12, 2021 at 06:09:47PM +0530, Harshvardhan Jha wrote: > The handle_bit_test condition wasn't setting a false range_list for the > false state and hence the implied rl was coming out to be false. The > false and true rls have been calculating using rl_intersection and > rl_filter commands. > Can you fix the commit message a bit. Assume that the person reading your patch understands Smatch basically but doesn't remember all the details. I like to give a little background. Here is my proposed commit message: Imagine we have code like: if ((1 << foo) & valid_bits) { The handle_bit_test() function is supposed to answer the question, "what does that mean about 'foo'"? This patch fixes several bugs: 1) The range is off by one. ffsll() returns 1 for BIT(0) so we need to subtract 1 from what ffsll() returns. 2) This code returns early for impossible conditions but it is better to set "foo" to the empty state. 3) The false state was not set. We can use rl_filter() for that. regards, dan carpenter