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

[Nicola Vetrini <nicola.vetrini@bugseng.com>]

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@epam.com>
>>>>> 
>>>>> 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://en.cppreference.com/c/string/byte/memchr

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253