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

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