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

[Jan Beulich <jbeulich@xxxxxxxx>]

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

> 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