Re: [PATCH v2] misra: add deviation of Rule 17.7

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 8/26/25 10:56, Nicola Vetrini wrote:
> On 2025-08-26 09:45, Jan Beulich wrote:
>> On 26.08.2025 09:36, Dmytro Prokopchuk1 wrote:
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> @@ -575,6 +575,11 @@ safe."
>>>  -config=MC3A2.R17.7,calls+={safe, "any()", 
>>> "decl(name(__builtin_memcpy||__builtin_memmove||__builtin_memset|| 
>>> cpumask_check))"}
>>>  -doc_end
>>>
>>> +-doc_begin="It is safe to deviate functions like 'memcpy()', 
>>> 'memset()', 'memmove()', as they return a value purely for convenience,
>>> +their primary functionality (memory manipulation) remains 
>>> unaffected, and their return values are generally non-critical and 
>>> seldom relied upon."
>>> +-config=MC3A2.R17.7,calls+={safe, "any()", "decl(name(memcpy|| 
>>> memset||memmove))"}
>>> +-doc_end
>>> +
>>>  #
>>>  # Series 18.
>>>  #
>>> --- a/docs/misra/deviations.rst
>>> +++ b/docs/misra/deviations.rst
>>> @@ -576,6 +576,13 @@ Deviations related to MISRA C:2012 Rules:
>>>           - __builtin_memset()
>>>           - cpumask_check()
>>>
>>> +   * - R17.7
>>> +     - It is safe to deviate functions like 'memcpy()', 'memset()', 
>>> 'memmove()',
>>> +       as they return a value purely for convenience, their primary 
>>> functionality
>>> +       (memory manipulation) remains unaffected, and their return 
>>> values are
>>> +       generally non-critical and seldom relied upon.
>>> +     - Tagged as `safe` for ECLAIR.
>>
>> I realize I may be overly nitpicky here, but in files named 
>> deviations.* I find it
>> odd to read "It is safe to deviate ...". I further find the use of 
>> "like" odd when
>> you enumerate the complete set anyway.

Updated wording (probably for the v3, if it's fine):

The functions 'memcpy()', 'memset()', and 'memmove()' return values 
primarily for convenience.
The core functionality of these functions (memory manipulation) remains 
unaffected, and their return values
are generally non-critical and seldom relied upon. Therefore, deviations 
from this rule regarding their use
can be considered safe.

Dmytro.

>>
>> I wonder whether the deviation wants generalizing anyway: 
>> Informational return
>> values are generally okay to ignore. That is, the Eclair configuration 
>> would be
>> limited to the three functions for now, but the text / comment could 
>> already be
>> broader. Then, for example, open-coded uses of the corresponding 
>> builtin functions
>> would also be covered right away.
>>
> 
> While I understand the pragmatic reasoning, from a MISRA compliance 
> standpoint it would be better not to make the written justification and 
> the actual deviation diverge, and then wide both the ECLAIR 
> configuration and its justification suitably once new cases want to be 
> deviated. Other than that,
> 
> Reviewed-by: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
>