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

[Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>]

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

> > 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).
> As this keeps coming up, we surely want to discuss / progress this 
> move.
> Jan
That makes a lot of sense. We could add to the next community call or 
maintainers/committers call to present the problem and propose a way 
forward so that all stakeholders are aware. From my side, I can explain 
what moving from one to the other can entail in terms of static 
analysis, while others (e.g. Andrew Cooper) may expand a bit on specific 
C11/C18 features is desirable aside from safety.
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253