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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

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

What I've got for now is all in
https://gitlab.com/xen-project/xen/-/work_items/201

We want _Generic() for const-correctness reasons only.  (And possibly
API transition work - this has mixed results but can substantially
reduce churn in a series if done well).

This depends on moving to C11, which we need to at some point anyway
even if weren't for _Generic().


The other area was the use of auto, but that's sorted now and will
continue to be an implementation extension until we get to the point of
considering C23.

~Andrew