Re: [PATCH] xsm: misra rule 8.4 fix

[Michal Orzel <michal.orzel@xxxxxxx>]

On 08/12/2022 09:14, Jan Beulich wrote:
> 
> 
> On 07.12.2022 13:33, Michal Orzel wrote:
>> Hi Stefano,
>>
>> On 07/12/2022 03:12, Stefano Stabellini wrote:
>>>
>>>
>>> Fix two MISRA Issues Rule 8.4 ("A compatible declaration shall be
>>> visible when an object or function with external linkage is defined")
>>> found by cppcheck affecting xen/xsm/flask/ss/services.c.
>>>
>>> Fix the first issue by making policydb_loaded_version static and the
>>> second issue by declaring ss_initialized in a proper header.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@xxxxxxx>
>>
>> cppcheck also reports findings for rule 8.4 with regards to the following 
>> functions:
>> - security_get_bools
>> - security_set_bools
>> - security_get_bool_value
>> - security_get_bool_name
>>
>> The prototypes for them are stored in xen/xsm/flask/include/conditional.h,
>> but services.c only does:
>> #include "conditional.h"
>>
>> This include refers to xen/xsm/flask/ss/conditional.h and not to 
>> xen/xsm/flask/include/conditional.h.
>> This means that we should also explicitly do:
>> #include <conditional.h>
> 
> And Misra has no rule disallowing such use of two different, identically
> named headers, for being potentially ambiguous?
I could not find such rule/directive related to filenames; only \wrt 
identifiers.
But all in all, we do not need MISRA to modify the filenames to get rid of 
ambiguity
if we really want to.

> 
> Jan

~Michal