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

Re: [RFC PATCH] xen/build: Add cppcheck and cppcheck-html make rules


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Fri, 25 Mar 2022 14:28:18 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.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=IcxYJgUoyj02MY9XCWeYicz3tx5jsdz6bEKKHLk2/yM=; b=V/jJzZ0gmDOi+qxaVkN3gvnewn7h18x4pUsnERl8wUUBqtpS/Wa36iVyTatY39iB9R0Ve1vO91lkBimyp0X7dQRp/U/B20gfNcSk5vYgY6iStcfQ2Gqb4d1LAh2klRL27ODe4Kg8ZO5E6mXQoWvM45XhxoyuSXshTCXecHx8iMVH/Z9WBvcXFj+MsqawUqRxI2zc5lCYSIMvNdyrt9ujwx9kFcoQsvicTQ8P0z+LyrYxegUMzh7Zert7b+8Kd0AM8ThexD07/7ZO2Qzj95N6YLKMPMWDNy03YfNXZgrHcYFW4hoQS6JNbIc3zZI+ubPALoVEj8SKQrj9/ho/xo+0UQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ce7/xGcn5ca+ekEzkJvJgaF/KQmrWrvGjhLtDvAuA4qbtF6aB1WcVQGMnWgVb2HL7aAJd4kCo/rNgmb8HO96Gk1u3RaO43XvtyoF+zld/bIrwBW2G14c3JKI1ksfx6XFli+U6t9xBTbFBk3fOOneldVmTzOgumMJVWFfcs5K7UwCNLkcXH09wPB11g/URhlJn4trmZpMhGLjpDN26CNiaoJvnUGSOmOsSQSSQhNrMM9xGXfqFwr+hzrq+d5BMpv9crsD2WIJXYsxJdz1GaiXRKW7T2kCBiNAZSt3WmfeoYrPOJMrzwaObm2S/+ejVeXd5mMlfFsjfV6li0GeFD/ouw==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Michal Orzel <Michal.Orzel@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Fri, 25 Mar 2022 14:28:50 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHYP279DnP7J8Edsk+NG7Po4Qnn9azP/EyAgAAUmoCAABRhgIAABP6A
  • Thread-topic: [RFC PATCH] xen/build: Add cppcheck and cppcheck-html make rules

Hi Jan,

> On 25 Mar 2022, at 15:10, Jan Beulich <jbeulich@xxxxxxxx> wrote:
> 
> On 25.03.2022 13:57, Bertrand Marquis wrote:
>>> On 25 Mar 2022, at 12:43, Jan Beulich <jbeulich@xxxxxxxx> wrote:
>>> On 24.03.2022 12:04, Bertrand Marquis wrote:
>>>> --- a/xen/include/xen/kconfig.h
>>>> +++ b/xen/include/xen/kconfig.h
>>>> @@ -8,6 +8,10 @@
>>>> * these only work with boolean option.
>>>> */
>>>> 
>>>> +/* cppcheck is failing to parse the macro so use a dummy one */
>>>> +#ifdef CPPCHECK
>>>> +#define IS_ENABLED(option) option
>>>> +#else
>>>> /*
>>>> * Getting something that works in C and CPP for an arg that may or may
>>>> * not be defined is tricky.  Here, if we have "#define CONFIG_BOOGER 1"
>>>> @@ -27,5 +31,6 @@
>>>> * otherwise.
>>>> */
>>>> #define IS_ENABLED(option) config_enabled(option)
>>>> +#endif
>>> 
>>> What are the consequences of this workaround on the code actually
>>> being checked? Does this perhaps lead to certain portions of code
>>> being skipped while checking?
>> 
>> Cppcheck is not optimising the code but looking at the syntax so the
>> consequence here is that cppcheck is checking some code which might
>> be optimised out by the compiler. This is not optimal but still it should
>> analyse properly the code.
> 
> Aren't you saying so merely because all uses of IS_ENABLED() in our
> sources so far are in if()? It would seem to me that when used in #if
> (as can be found in Linux, which hence means could be the case in our
> tree as well sooner or later) sections of code might either be skipped
> or syntax errors may result. Or wait - IS_ENABLED() does itself kind
> of rely on the respective CONFIG_* to expand to a numeric value; when
> expanding to a string, I guess the compiler would also warn about the
> resulting construct when used in if() (and reject any uses with #if).

I am not quite sure I am following what you are saying (or asking).

I say that most use cases are if (IS_ENABLED(x)) so from the syntax point
of view it is ok to not do exactly as IS_ENABLED really does. And
cppcheck is checking the code not the result.
Now it would be better to do it right but the point of the patch is to enable
cppcheck not make it perfect on the first shot.

Cheers
Bertrand

> 
> Jan
> 




 


Rackspace

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