Re: [PATCH] misra: deviate C library-style functions from Misra C:2012 rule 11.8

[Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>]

On 10/5/26 00:05, Nicola Vetrini wrote:
> On 2026-10-01 14:39, Andrew Cooper wrote:
>> On 29/09/2026 6:52 pm, Nicola Vetrini wrote:
>>> On 2026-09-29 17:11, Jan Beulich wrote:
>>>> On 29.09.2026 16:56, Nicola Vetrini wrote:
>>>>> On 2026-09-29 15:40, Jan Beulich wrote:
>>>>>> On 29.09.2026 11:03, Dmytro Prokopchuk1 wrote:
>>>>>>> bsearch(), memchr(), memchr_inv(), strchr(), strpbrk(), strrchr() 
>>>>>>> and
>>>>>>> strstr() all accept a const pointer/object but return a non-const
>>>>>>> pointer
>>>>>>> to the matched element or byte, matching their standard C library
>>>>>>> interfaces. The const qualifier is deliberately stripped so that
>>>>>>> callers
>>>>>>> searching a non-const object get back a mutable pointer to it. 
>>>>>>> Fixing
>>>>>>> this would require changing the public API, so document these 
>>>>>>> uses as
>>>>>>> deviations instead.
>>>>>>>
>>>>>>> Update docs/misra/rules.rst to note that this class of double-use
>>>>>>> library functions is deviated on a per-function basis.
>>>>>>>
>>>>>>> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>
>>>>>>
>>>>>> When I prepared my 11.8 series [1], I was wondering whether we 
>>>>>> need to
>>>>>> go
>>>>>> as far as deviating these. Since we now uniformly take gcc5 as 
>>>>>> minimum
>>>>>> baseline, there is (at least in theory) the option of using
>>>>>> _Generic to
>>>>>> cover the dual-use. One question there is whether Eclair would
>>>>>> recognize
>>>>>> such - Nicola? After all, looking at e.g. glibc's implementation, the
>>>>>> functions themselves remain "unsafe" there; it's a macro wrapping 
>>>>>> them
>>>>>> which puts the lost qualifier back.
>>>>>
>>>>> Could you provide a concrete example?
>>>>
>>>> From glibc 2.43:
>>>>
>>>> # define __glibc_const_generic(PTR, CTYPE, CALL)    \
>>>>   _Generic (0 ? (PTR) : (void *) 1,            \
>>>>         const void *: (CTYPE) (CALL),        \
>>>>         default: CALL)
>>>>
>>>> while the declarations still are e.g.
>>>>
>>>> extern void *memchr (const void *__s, int __c, size_t __n)
>>>>       __THROW __attribute_pure__ __nonnull ((1));
>>>>
>>>> (and hence the implementation still - necessarily - casts away
>>>> const-ness).
>>>>
>>>
>>> Ok, will look into that
>>
>> We are going to have to deviate the implementation, even if we are using
>> _Generic() to force const-correct behaviour from the callers.
>>
>> We could duplicate the functions, but there's a different rule about
>> that.  We can't use ELF aliasing tricks because that breaks software
>> type-hashing techniques for control-flow integrity.
>>
> 
> Yeah. The internal cast is clearly still signaled by ECLAIR, regardless 
> of the surrounding context. That being said, the trick is quite nice and 
> it would actually be a stronger argument for a deviation in my opinion: 
> it mitigates the risk pointed out by the MISRA rule at the callsites. It 
> is also true that the C23 signature is a lot nicer in terms of typing [1].
> 
> There's a slight friction with MISRA C Rule 23.5 ("A generic selection 
> should not depend on implicit pointer type conversion") from MISRA 
> C:2012 Amendment 3 for the non-const input case, because the type of the 
> controlling expression could match either alternative depending on the 
> context, but that's not a strong concern (Advisory rule, no associated UB).
> 
> [1] https://eur01.safelinks.protection.outlook.com/? 
> url=https%3A%2F%2Fen.cppreference.com%2Fc%2Fstring%2Fbyte%2Fmemchr&data=05%7C02%7Cdmytro_prokopchuk1%40epam.com%7C3402c71c34a844fdfaed08df225b3d77%7Cb41b72d04e9f4c268a69f949f367c91d%7C1%7C0%7C639267447530756053%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0NM2ftsbEg98wGci7zbNyy%2BoESvP%2BqfU7%2Bz5OQKnNcc%3D&reserved=0
> 

Combining all comments and answers I see the next steps to this patch:

- drop memchr_inv() from the deviation
- anchor the file patterns as ^...$||^...$
- group the xen/lib files together
- narrow the justification to the casts in the function bodies.

Any suggestions?


BR, Dmytro.