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

[Jan Beulich <jbeulich@xxxxxxxx>]

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).

Jan