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.vetr...@bugseng.com>
>
