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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

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