[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] misra: deviate C library-style functions from Misra C:2012 rule 11.8
- To: Jan Beulich <jbeulich@xxxxxxxx>
- From: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
- Date: Tue, 29 Sep 2026 16:56:07 +0200
- Arc-authentication-results: i=1; bugseng.com; arc=none smtp.remote-ip=162.55.131.47
- Arc-message-signature: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; c=relaxed/relaxed; t=1790693767; h=MIME-Version:Date:From:To:Cc:Subject:In-Reply-To:References: Message-ID:X-Sender:Organization:Content-Type: Content-Transfer-Encoding; bh=YGQwRXEiV7XZt9L+YrtPG7YGT7ZQb707ksQJ0k6m2tc=; b=1hqWzmai0AeSygfdQwDDdsh/8IQoc+IrmiKFs7r7nk+lqI3LKLNoOQy0PCyCsNEjyfon O+II1kEAxkLY00LfQYE3jt+K2Aa4RAIJHXpz//N3PJCjLhIUpufqdEeFsSmS0O/xB6lpL tC0ZMUkosLDf9bKrXrLquuJRumGDKOfRwZNf2DiTa0fLk8/fBHFHiukr+Rcv8Y2yESL9H 09soJzgaPkBQcRl8yP0aTY7H8YRcRI2Kf8NN/N0BBZnvJr0hdd2SRFLGSouGw85/d5DBV GAcjT1DOrYFCPu5rUS1WqfxRmpW0UbQXpRIq6KVEOw9eYCI0hwgMpKUjfCNNEOagI4O2X PLiqGFIaKFeVCILquoidQlUFAmnLPeUt25K3ATlBaQIdybpfNtkDnvjnEhleoc+h5T1wA lqxUbjmjv439mxxyD/gWOKo8FoAhol1+rVBuY4RescRgHR18Ppb96z5MMo2+hLqDeCHFl ty8x8UKAyrwqYskmPuyyuC5Y9rFF6+JfGDu5CTzUKVQJCUjICvr3t5anZHcT+Wj9hGkq8 VuarSbYg/ykLciy/PaZ5kOoMFunpI5oQ56HCHp/TOsdcixG0QFgPJwRC9pMfsdH1hArXk RVxs9w5MVucv3Y9tKejmp+1wDMSJMSqLgirvDawRSoUaxo7bZtG9Fkjjg3bJbCU=
- Arc-seal: i=1; d=bugseng.com; s=openarc; a=rsa-sha256; cv=none; t=1790693767; b=Jib0RG10X/mtZBaLKJ8/HYrIgQ4lMeBAOxdYj0iUqR3FWVEBhm+zcVPlA1wX6Hlr2Ctd A3cOSjFmsGCWXDlFsZsgNMlAKVIjdN0UqQ5NFVYWc2fXyPtQtiLlruBlBeflAh8u2ROGM CsOl/XwDrwmI9gJZ0eyx1FTGTtf+Ithxg4cIooV5xrosL/M85UoycI/s+a7oeG9pWZ9tc 85x3bbjTiyEyEWSVxJhljXzZgpyoE0tjTc2HRhO2qC61s4t3XqxQEoUiv8+MDl19HeSA6 YvV1EqsU5nIt5gRLBFqeRvuDtNe3NGBgpa7KNtJTPWIzxuQvuLcPEWc99Fru1TpFq5YTJ 973BrIb//aO2XGzsx5ue8DKH3Px4pOqp3AfK430GiVN48PKaeu26vIVjEGkJ5bDYpSlKC BDUQbTNiOJsh7+5WUfqx0BOZxnnXs4LceDJ1Mds3ec4tEbnzASl1xkuHNqzypkB9yUIkR 8anqPB4WZTMehhv3+UEetVpVQ6QicgT+BpNxuGqpqDDGzgUBSdeUPHV3ENjLLCtTLkp9g UUDybptsNe3VatWlVTlX/2NMAJI6Oi2lMoK7xW+nBBC1tGoQ5MtAtEfbhTFGZrFx3fYTH nAVHIYZRxHmvWu+qh2vJ1mEMGdPjgAAX0ehNOl3vEHqFAA4MNkXPBpl/GFWRtOo=
- Authentication-results: eu.smtp.expurgate.cloud; none
- Authentication-results: bugseng.com; arc=none smtp.remote-ip=162.55.131.47
- Cc: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Tue, 29 Sep 2026 14:56:12 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
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? 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).
Another question is about memchr_inv(): That's not a standard function,
and hence it also doesn't need to strictly follow the pattern of those
other functions. In no case should it, imo, be mixed with the standard
functions without mentioning the difference.
Jan
[1] https://lists.xen.org/archives/html/xen-devel/2026-09/msg00036.html
--
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253
|
