[PATCH] docs/misra/rules.rst: allow string literals with memcmp

Stefano Stabellini posted 1 patch 4 months, 1 week ago
Failed in applying to current master (apply log)
[PATCH] docs/misra/rules.rst: allow string literals with memcmp
Posted by Stefano Stabellini 4 months, 1 week ago
Rule 21.16 is about the types of arguments allowed for memcpy. Add
string literals to the allow-list under specific conditions.

Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Stefano Stabellini <stefano.stabellini@amd.com>

diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index e1c26030e8..3e014a6298 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -813,7 +813,9 @@ maintainers if you want to suggest a change.
        shall point to either a pointer type, an essentially signed type,
        an essentially unsigned type, an essentially Boolean type or an
        essentially enum type
-     - void* arguments are allowed
+     - void* arguments are allowed. string literal arguments are allowed
+       when the last argument passed for the comparison is less or equal
+       to the size of the string.
 
    * - `Rule 21.17 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_21_17.c>`_
      - Mandatory
Re: [PATCH] docs/misra/rules.rst: allow string literals with memcmp
Posted by Jan Beulich 4 months, 1 week ago
On 24.06.2025 01:45, Stefano Stabellini wrote:
> Rule 21.16 is about the types of arguments allowed for memcpy.

Seeing the subject - is it memcmp(), memcpy(), or both? (Writing from
home, where I don't have the Misra spec to hand, and hence can't check
what coverage the rule has.)

Jan
Re: [PATCH] docs/misra/rules.rst: allow string literals with memcmp
Posted by Nicola Vetrini 4 months ago
On 2025-06-24 08:11, Jan Beulich wrote:
> On 24.06.2025 01:45, Stefano Stabellini wrote:
>> Rule 21.16 is about the types of arguments allowed for memcpy.
> 
> Seeing the subject - is it memcmp(), memcpy(), or both? (Writing from
> home, where I don't have the Misra spec to hand, and hence can't check
> what coverage the rule has.)
> 
> Jan

In this case the rule covers just memcmp(): "The pointer arguments to 
the Standard Library function memcmp shall point to either a pointer 
type, an essentially signed type, an essentially unsigned type, an 
essentially Boolean type or an essentially enum type"

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
Re: [PATCH] docs/misra/rules.rst: allow string literals with memcmp
Posted by Stefano Stabellini 3 months, 3 weeks ago
On Thu, 26 Jun 2025, Nicola Vetrini wrote:
> On 2025-06-24 08:11, Jan Beulich wrote:
> > On 24.06.2025 01:45, Stefano Stabellini wrote:
> > > Rule 21.16 is about the types of arguments allowed for memcpy.
> > 
> > Seeing the subject - is it memcmp(), memcpy(), or both? (Writing from
> > home, where I don't have the Misra spec to hand, and hence can't check
> > what coverage the rule has.)
> > 
> > Jan
> 
> In this case the rule covers just memcmp(): "The pointer arguments to the
> Standard Library function memcmp shall point to either a pointer type, an
> essentially signed type, an essentially unsigned type, an essentially Boolean
> type or an essentially enum type"

Jan, given the above, any chance you can ack it?
Re: [PATCH] docs/misra/rules.rst: allow string literals with memcmp
Posted by Jan Beulich 3 months, 3 weeks ago
On 07.07.2025 23:45, Stefano Stabellini wrote:
> On Thu, 26 Jun 2025, Nicola Vetrini wrote:
>> On 2025-06-24 08:11, Jan Beulich wrote:
>>> On 24.06.2025 01:45, Stefano Stabellini wrote:
>>>> Rule 21.16 is about the types of arguments allowed for memcpy.
>>>
>>> Seeing the subject - is it memcmp(), memcpy(), or both? (Writing from
>>> home, where I don't have the Misra spec to hand, and hence can't check
>>> what coverage the rule has.)
>>
>> In this case the rule covers just memcmp(): "The pointer arguments to the
>> Standard Library function memcmp shall point to either a pointer type, an
>> essentially signed type, an essentially unsigned type, an essentially Boolean
>> type or an essentially enum type"
> 
> Jan, given the above, any chance you can ack it?

With the description corrected:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan