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

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 8/26/25 10: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.
> 
> 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.
> 
> Jan

Yes, fully agree with you.
I'll update it.
Thanks.

Dmytro.