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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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://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