| Message ID | 4a2c68bdc11a815cb8531be305e2e7fc4bef7779.1736240655.git.alessandro.zucchelli@bugseng.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v3] misra: add deviation for MISRA C Rule R11.8. | expand |
On 07.01.2025 10:10, Alessandro Zucchelli wrote: > --- a/docs/misra/deviations.rst > +++ b/docs/misra/deviations.rst > @@ -353,6 +353,13 @@ Deviations related to MISRA C:2012 Rules: > Fixing this violation would require to increase code complexity and lower readability. > - Tagged as `safe` for ECLAIR. > > + * - R11.8 > + - Violations caused by function __hvm_copy occour when a const void attribute is passed, > + as the const qualifier is stripped. However, in such cases, the function ensures > + that it does not modify the attribute, therefore, this use is deemed safe. > + Fixing this violation would require to increase code complexity and lower readability. > + - Tagged as `safe` for ECLAIR. Do you really mean "attribute" in both places the word is used? In the first case talk appears to be of a function argument / parameter, while in the second case it looks to be the buffer referenced be the argument / parameter which is meant. Jan
On Tue, 7 Jan 2025, Jan Beulich wrote: > On 07.01.2025 10:10, Alessandro Zucchelli wrote: > > --- a/docs/misra/deviations.rst > > +++ b/docs/misra/deviations.rst > > @@ -353,6 +353,13 @@ Deviations related to MISRA C:2012 Rules: > > Fixing this violation would require to increase code complexity and lower readability. > > - Tagged as `safe` for ECLAIR. > > > > + * - R11.8 > > + - Violations caused by function __hvm_copy occour when a const void attribute is passed, > > + as the const qualifier is stripped. However, in such cases, the function ensures > > + that it does not modify the attribute, therefore, this use is deemed safe. > > + Fixing this violation would require to increase code complexity and lower readability. > > + - Tagged as `safe` for ECLAIR. > > Do you really mean "attribute" in both places the word is used? In the > first case talk appears to be of a function argument / parameter, while > in the second case it looks to be the buffer referenced be the > argument / parameter which is meant. Yes I can see what Jan is saying. What about: Violations caused by function __hvm_copy occur when a const void argument is passed, as the const qualifier is stripped. However, in such cases, the function ensures that it does not modify the buffer referenced by the argument, therefore, this use is deemed safe. Fixing this violation would require to increase code complexity and lower readability.
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index 2f58f29203..c9d06b44f4 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -393,6 +393,12 @@ Fixing this violation would require to increase code complexity and lower readab -config=MC3R1.R11.8,reports+={safe,"any_area(any_loc(any_exp(macro(^container_of$))))"} -doc_end +-doc_begin="Function __hvm_copy in xen/arch/x86/hvm/hvm.c is a double-use +function, where the parameter needs to not be const because it can be set for +write or not" +-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(text(^.*__hvm_copy.*HVMCOPY_to_guest doesn't modify.*$)))"} +-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=MC3R1.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 15a993d050..92dcc91e3a 100644 --- a/docs/misra/deviations.rst +++ b/docs/misra/deviations.rst @@ -353,6 +353,13 @@ Deviations related to MISRA C:2012 Rules: Fixing this violation would require to increase code complexity and lower readability. - Tagged as `safe` for ECLAIR. + * - R11.8 + - Violations caused by function __hvm_copy occour when a const void attribute is passed, + as the const qualifier is stripped. However, in such cases, the function ensures + that it does not modify the attribute, therefore, this use is deemed safe. + Fixing this violation would require to increase code complexity and lower readability. + - 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
Rule 11.8 states as following: "A cast shall not remove any `const' or `volatile' qualification from the type pointed to by a pointer". Function `__hvm_copy' in `xen/arch/x86/hvm/hvm.c' is a double-use function, where the parameter needs to not be const because it can be set for write or not. As it was decided a new const-only function will lead to more developer confusion than it's worth, this violation is addressed by deviating the function. All cases of casting away const-ness are accompanied with a comment explaining why it is safe given the other flags passed in; such comment is used by the deviation in order to match the appropriate function call. No functional change. Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com> --- Changes from V2: The deviation has been documented under docs/misra/deviations.rst. Changes from V1: The deviation has been refined to specify that every instance of casting away const-ness is accompanied by a comment explaining why it is safe. This comment is a requirement that has been incorporated into the text defining the deviation. --- automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++++ docs/misra/deviations.rst | 7 +++++++ 2 files changed, 13 insertions(+)