All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicola Vetrini <nicola.vetrini@bugseng.com>
To: Dmytro Prokopchuk1 <dmytro_prokopchuk1@epam.com>
Cc: xen-devel@lists.xenproject.org,
	"Doug Goldstein" <cardoe@cardoe.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Jan Beulich" <jbeulich@suse.com>,
	"Julien Grall" <julien@xen.org>,
	"Roger Pau Monné" <roger@xenproject.org>
Subject: Re: [PATCH v2] misra: deviate C library-style functions from Misra C:2012 rule 11.8
Date: Tue, 27 Oct 2026 08:29:11 +0100	[thread overview]
Message-ID: <9cef9d25d9c1dc136db0e356db4e98c3@bugseng.com> (raw)
In-Reply-To: <cab890c77bfbb016e79f847d6dfddac993079f40.1792406297.git.dmytro_prokopchuk1@epam.com>

On 2026-10-19 12:41, Dmytro Prokopchuk1 wrote:
> bsearch(), memchr(), 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 casts in these implementations strip const so that callers 
> searching
> a non-const object get back a mutable pointer. 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>

Reviewed-by: Nicola Vetrini <nicola.vetrini@bugseng.com> # 
automation/eclair_analysis/.*

> ---
> Changes in v2:
> - dropped memchr_inv() from the deviation (not a standard function)
> - anchored the file patterns and grouped the xen/lib files, as
>   suggested by Nicola
> - narrowed the justification to the casts in the function bodies
> 
> Link to v1:
> https://patchew.org/Xen/4abcb11ef287170ced74935cbee60c90058c1307.1790671787.git.dmytro._5Fprokopchuk1@epam.com/
> ---
>  automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
>  docs/misra/deviations.rst                        | 9 +++++++++
>  docs/misra/rules.rst                             | 6 +++++-
>  3 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
> b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 6cdb10a129..ed8bad0cb0 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -450,6 +450,14 @@ write or not"
>  
> -config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(file(hvm_guestcopy)&&text(^.*__hvm_copy.*HVMCOPY_to_guest 
> doesn't modify.*$)))"}
>  -doc_end
> 
> +-doc_begin="Functions bsearch(), memchr(), strchr(), strpbrk(), 
> strrchr() and
> +strstr() accept a const pointer/object and return a non-const pointer 
> to the
> +matched element or byte, matching their standard C library interfaces. 
> The
> +casts in these implementations strip const so that a search of a 
> non-const
> +object yields a mutable pointer. This use is deemed safe."
> +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(file(^xen/include/xen/bsearch\\.h$||^xen/lib/(memchr|strchr|strpbrk|strrchr|strstr)\\.c$)))"}
> +-doc_end
> +
>  -doc_begin="This construct is used to check if the type is scalar, and 
> for this purpose the use of 0 as a null pointer constant is 
> deliberate."
>  -config=MC3A2.R11.9,reports+={deliberate, 
> "any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))"
>  }
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index 6bcc2adf95..68de2d8dd1 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -436,6 +436,15 @@ Deviations related to MISRA C:2012 Rules:
>         readability.
>       - Tagged as `safe` for ECLAIR.
> 
> +   * - R11.8
> +     - Functions bsearch(), memchr(), strchr(), strpbrk(), strrchr() 
> and
> +       strstr() accept a const pointer/object and return a non-const 
> pointer
> +       to the matched element or byte, matching their standard C 
> library
> +       interfaces. The casts in these implementations strip const so 
> that a
> +       search of a non-const object yields a mutable pointer. This use 
> is
> +       deemed safe.
> +     - Tagged as `safe` for ECLAIR.
> +
>     * - R11.9
>       - __ACCESS_ONCE uses an integer, which happens to be zero, as a
>         compile time check. The typecheck uses a cast. The usage of 
> zero or other
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index a59cf1782e..00378c474e 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -473,7 +473,11 @@ maintainers if you want to suggest a change.
>     * - `Rule 11.8 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_08.c>`_
>       - Required
>       - A cast shall not remove any const or volatile qualification 
> from the type pointed to by a pointer
> -     -
> +     - Some standard C library-style functions are inherently 
> double-use,
> +       accepting a const argument and returning a non-const pointer 
> into
> +       it so that callers searching a non-const object get back a
> +       mutable pointer. The casts that implement this are deviated per
> +       function.
> 
>     * - `Rule 11.9 
> <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_09.c>`_
>       - Required

-- 
Nicola Vetrini, B.Sc.
Software Engineer
BUGSENG (https://bugseng.com)
LinkedIn: https://www.linkedin.com/in/nicola-vetrini-a42471253


      parent reply	other threads:[~2026-10-27  7:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 10:41 [PATCH v2] misra: deviate C library-style functions from Misra C:2012 rule 11.8 Dmytro Prokopchuk1
2026-10-26 11:09 ` Jan Beulich
2026-10-27  7:29 ` Nicola Vetrini [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9cef9d25d9c1dc136db0e356db4e98c3@bugseng.com \
    --to=nicola.vetrini@bugseng.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=cardoe@cardoe.com \
    --cc=dmytro_prokopchuk1@epam.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=roger@xenproject.org \
    --cc=sstabellini@kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.