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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

On 2025-08-26 15:14, Dmytro Prokopchuk1 wrote:
> 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.
The last sentence reads a little strangely. I would write: "Therefore, 
violations of this rule due to these functions are deemed 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>
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253