On 19/10/2023 09:03, Jan Beulich wrote:
On 19.10.2023 02:54, Stefano Stabellini wrote:
On Thu, 19 Oct 2023, [email protected] wrote:
On 18/10/2023 2:42 pm, Nicola Vetrini wrote:
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index ee7aed0609d2..1b00e4e3e9b7 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -199,6 +199,11 @@ Deviations related to MISRA C:2012 Rules:
See automation/eclair_analysis/deviations.ecl for the full
explanation.
- Tagged as `safe` for ECLAIR.
+ * - R11.9
+ - __ACCESS_ONCE uses a 0 as a null pointer constant to check
if a type is
+ scalar, therefore its usage for this purpose is allowed.
This is still deeply misleading.
There is an integer, which happens to be 0 but could be anything,
used
for a compile time typecheck[1]. In some cases this may be
interpreted
as a pointer constant, and is permitted for this purpose.
~Andrew
[1] I know I wrote scalar typecheck in the comment, but I suspect
that
what I actually meant was non-compound-type typecheck.
To help Nicola find the right wording do you have a concrete
suggestion
for the text to use?
Reading your reply, I am guessing it would be:
* - R11.9
- __ACCESS_ONCE uses an integer, which happens to be zero, as a
non-compound-type typecheck. The typecheck uses a cast. The usage
of
zero or other integers for this purpose is allowed.
"non-compound" isn't correct either: __int128_t, for example, isn't a
compound type but may not be used with ACCESS_ONCE(). Furthermore
certain compound types are, as indicated earlier, in principle okay
to use with ACCESS_ONCE(). Both are shortcomings of the present
implementation, which imo shouldn't propagate into this document. I'd
say just "as a compile time check".
Jan
Ok, I'll amend it
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
