On 19.10.2023 02:54, Stefano Stabellini wrote: > On Thu, 19 Oct 2023, andrew.coop...@citrix.com 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
