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

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

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? In passing, for stronger 
guarantees w.r.t. _Generic it would be better to switch to MISRA C:2012 
Amendment 3, which has specific support for that feature. Keeping AMD2 
and using _Generic weakens a bit the safety argument (though one can do 
an analysis himself, of course).

> Another question is about memchr_inv(): That's not a standard function,
> and hence it also doesn't need to strictly follow the pattern of those
> other functions. In no case should it, imo, be mixed with the standard
> functions without mentioning the difference.
> 
> Jan
> 
> [1] https://lists.xen.org/archives/html/xen-devel/2026-09/msg00036.html

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