[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH] xen: fixed violations of MISRA C:2012 Rule 3.1


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 14 Jun 2023 17:05:16 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=LY0fDI1COrRAPItFK+DtKq5z44jVdpW5FeMRvsr/wGY=; b=ag881cgLObosxLOZIB+We69bNjkZB5yH9hSFVpu3oa/jdGQxsx+kIFogTmseTXoNHWsw0LJUcP3IeSLgaIMeVl/nuNJlJ/zRhP+Nf0XnZ5FIvW+6efI5ubnzdxtHIEEJDISDKv6SJvjoitjz567P/gHSHNWUuLwA3lawFDyKCm5UuNr8V8W8M/MxRaI215fLLAOEFmNi9du4LfdHvZr5neBdbea2E5xRTYJghXTfG4PO1zGFFwn+xJKB898f/fYjKr6ym4MxT6syrV4ZmFoVfxR0b21W3qw4BxRazAYYowLVlwOt2RIiYnpTcZNdNBQKW0KiHv0kdmo6B5oEQ1rbVA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cBh75qghp+5CWCBmv0xt6Psy4vsw3xe2pJSRPuAH1rVGV1JD/JNOQLRvxMMzutTer/puPjROKgstdZmrUvnE9uHCqzbgfrpawujMBLqDaIJE4YfMYsFb3fqppxEzHx+5LFRRXiHWshnveZD1mC3e8ip1mOeEAb5wH1yq06QbEf0esK7fLraayawu1T5uzsiuiDXkPR+OOcYLWoRYWpmpxIezQ72bhmkVulYa5gubIshpkgeXf11VLm0ZuelRD3/tkEDrG3Trbbm01nOrMKeOTAezqtlqPiYrrC1HcJXr9kQWbXOy4vefBmTKzj9/QBoBllXb1MCSZp5g5GJbXIbKYQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: consulting@xxxxxxxxxxx, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • Delivery-date: Wed, 14 Jun 2023 15:05:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 14.06.2023 16:28, Andrew Cooper wrote:
> On 13/06/2023 8:42 am, Nicola Vetrini wrote:
>> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
>> index 75bdf18c4e..ea6ec47a59 100644
>> --- a/xen/common/xmalloc_tlsf.c
>> +++ b/xen/common/xmalloc_tlsf.c
>> @@ -140,9 +140,10 @@ static inline void MAPPING_SEARCH(unsigned long *r, int 
>> *fl, int *sl)
>>          *fl = flsl(*r) - 1;
>>          *sl = (*r >> (*fl - MAX_LOG2_SLI)) - MAX_SLI;
>>          *fl -= FLI_OFFSET;
>> -        /*if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
>> -         *fl = *sl = 0;
>> -         */
>> +#if 0
>> +        if ((*fl -= FLI_OFFSET) < 0) // FL will be always >0!
>> +        fl = *sl = 0;
>> +#endif
>>          *r &= ~t;
>>      }
>>  }
> 
> This logic has been commented out right from it's introduction in c/s
> 9736b76d829b2d in 2008, and never touched since.
> 
> I think it can safely be deleted, and not placed inside an #if 0.

I have to admit that I wouldn't be happy with deleting without any
replacement. Instead of the commented out code, how about instead
having ASSERT(*fl >= 0)? (What isn't clear to me is whether the
commented out code is actually meant to replace the earlier line,
rather than (optionally) be there in addition - at least it very
much looks like so. With such an uncertainty I'd be further
inclined to not remove what's there.)

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.