| Message ID | 98bc1d90b93856ed7516a19114facf6528120248.1696494834.git.nicola.vetrini@bugseng.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | address violations of MISRA C:2012 Rule 11.9 | expand |
On Thu, 5 Oct 2023, Nicola Vetrini wrote: > The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a > compile-time check to detect non-scalar types; its usage for this > purpose is documented in rules.rst as an exception. > > Furthermore, the 'access_field' and 'typeof_field' macros are > introduced as a general way to deal with accesses to structs > without declaring a struct variable. > > Cleanup of spurious MISRA deviations. > > No functional change intended. > > Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > --- > If NULL is not suitable for usage inside access_field, then 0 could > be put there and the macro deviated. I think that's OK but let's wait to see if anyone else has a different feedback > --- > .../eclair_analysis/ECLAIR/deviations.ecl | 23 +++++++------------ > docs/misra/rules.rst | 3 ++- > xen/include/xen/compiler.h | 5 +++- > xen/include/xen/kernel.h | 2 +- > 4 files changed, 15 insertions(+), 18 deletions(-) > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl > index d8170106b449..acd42386e0a9 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -110,10 +110,6 @@ neither functions nor pointers to functions." > -config=MC3R1.R5.5,reports={safe,"all_area(decl(node(enum_decl||record_decl||field_decl||param_decl||var_decl)&&!type(canonical(address((node(function||function_no_proto))))))||macro(function_like()))"} > -doc_end > > --doc_begin="The use of these identifiers for both macro names and other entities > -is deliberate and does not generate developer confusion." > --config=MC3R1.R5.5,reports+={safe, "any_area(text(^\\s*/\\*\\s+SAF-[0-9]+-safe\\s+MC3R1\\.R5\\.5.*$, begin-1))"} > --doc_end > > -doc_begin="The definition of macros and functions ending in '_bit' that use the > same identifier in 'bitops.h' is deliberate and safe." > @@ -156,11 +152,6 @@ particular use of it done in xen_mk_ulong." > -config=MC3R1.R7.2,reports+={deliberate,"any_area(any_loc(macro(name(BUILD_BUG_ON))))"} > -doc_end > > --doc_begin="The following string literals are assigned to pointers to non > -const-qualified char." > --config=MC3R1.R7.4,reports+={safe, "any_area(text(^\\s*/\\*\\s+SAF-[0-9]+-safe\\s+MC3R1\\.R7\\.4.*$, begin-1))"} > --doc_end > - > -doc_begin="Allow pointers of non-character type as long as the pointee is > const-qualified." > -config=MC3R1.R7.4,same_pointee=false > @@ -222,12 +213,6 @@ definition is compiled-out or optimized-out by the compiler)" > # Series 9. > # > > --doc_begin="The following variables are written before being set, therefore no > -access to uninitialized memory locations happens, as explained in the deviation > -comment." > --config=MC3R1.R9.1,reports+={safe, "any_area(text(^\\s*/\\*\\s+SAF-[0-9]+-safe\\s+MC3R1\\.R9\\.1.*$, begin-1))"} > --doc_end > - > -doc_begin="Violations in files that maintainers have asked to not modify in the > context of R9.1." > -file_tag+={adopted_r9_1,"^xen/arch/arm/arm64/lib/find_next_bit\\.c$"} > @@ -274,6 +259,14 @@ still non-negative." > -config=MC3R1.R10.1,etypes+={safe, "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))", "dst_type(ebool||boolean)"} > -doc_end > > +# > +# Series 11 > +# > + > +-doc_begin="This macro 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$))))"} > +-doc_end > + > ### Set 3 ### > > # > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > index 3139ca7ae6dd..d5569696b3a8 100644 > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -393,7 +393,8 @@ maintainers if you want to suggest a change. > * - `Rule 11.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_09.c>`_ > - Required > - The macro NULL shall be the only permitted form of null pointer constant > - - > + - Using 0 as a null pointer constant to check if a type is scalar is > + allowed and always happens through the macro __ACCESS_ONCE. > > * - `Rule 12.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_12_05.c>`_ > - Mandatory > diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h > index dd99e573083f..15be9a750b23 100644 > --- a/xen/include/xen/compiler.h > +++ b/xen/include/xen/compiler.h > @@ -109,13 +109,16 @@ > > #define offsetof(a,b) __builtin_offsetof(a,b) > > +/* Access the field of structure type, without defining a local variable */ > +#define access_field(type, member) (((type *)NULL)->member) > +#define typeof_field(type, member) typeof(access_field(type, member)) > /** > * sizeof_field(TYPE, MEMBER) > * > * @TYPE: The structure containing the field of interest > * @MEMBER: The field to return the size of > */ > -#define sizeof_field(TYPE, MEMBER) sizeof((((TYPE *)0)->MEMBER)) > +#define sizeof_field(TYPE, MEMBER) sizeof(access_field(TYPE, MEMBER)) > > #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L > #define alignof __alignof__ > diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h > index 46b3c9c02625..2c5ed7736c99 100644 > --- a/xen/include/xen/kernel.h > +++ b/xen/include/xen/kernel.h > @@ -51,7 +51,7 @@ > * > */ > #define container_of(ptr, type, member) ({ \ > - typeof( ((type *)0)->member ) *__mptr = (ptr); \ > + typeof_field(type, member) *__mptr = (ptr); \ > (type *)( (char *)__mptr - offsetof(type,member) );}) > > /* > -- > 2.34.1 >
Hi, On 05/10/2023 09:45, Nicola Vetrini wrote: > The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a > compile-time check to detect non-scalar types; its usage for this > purpose is documented in rules.rst as an exception. Documenting ACCESS_ONCE() in rules.rst seems a bit odd. I am guessing that other analysis tool may point out the same error and therefore it would seem more appropriate to use a deviation. This would also avoid having a specific rule in the Eclair configuration for __ACCESS_ONCE(). > > Furthermore, the 'access_field' and 'typeof_field' macros are > introduced as a general way to deal with accesses to structs > without declaring a struct variable. > > Cleanup of spurious MISRA deviations. Please don't do that. This is making the review of the patches a lot more complicated because there are unrelated changes (see [1]). We often allow simple clean-up if they are in the context. But this is not the case here. > > No functional change intended. > > Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> > --- > If NULL is not suitable for usage inside access_field, then 0 could > be put there and the macro deviated. > --- > .../eclair_analysis/ECLAIR/deviations.ecl | 23 +++++++------------ > docs/misra/rules.rst | 3 ++- > xen/include/xen/compiler.h | 5 +++- > xen/include/xen/kernel.h | 2 +- > 4 files changed, 15 insertions(+), 18 deletions(-) > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl > index d8170106b449..acd42386e0a9 100644 > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl > @@ -110,10 +110,6 @@ neither functions nor pointers to functions." > -config=MC3R1.R5.5,reports={safe,"all_area(decl(node(enum_decl||record_decl||field_decl||param_decl||var_decl)&&!type(canonical(address((node(function||function_no_proto))))))||macro(function_like()))"} > -doc_end > > --doc_begin="The use of these identifiers for both macro names and other entities > -is deliberate and does not generate developer confusion." > --config=MC3R1.R5.5,reports+={safe, "any_area(text(^\\s*/\\*\\s+SAF-[0-9]+-safe\\s+MC3R1\\.R5\\.5.*$, begin-1))"} > --doc_end > > -doc_begin="The definition of macros and functions ending in '_bit' that use the > same identifier in 'bitops.h' is deliberate and safe." > @@ -156,11 +152,6 @@ particular use of it done in xen_mk_ulong." > -config=MC3R1.R7.2,reports+={deliberate,"any_area(any_loc(macro(name(BUILD_BUG_ON))))"} > -doc_end > > --doc_begin="The following string literals are assigned to pointers to non > -const-qualified char." > --config=MC3R1.R7.4,reports+={safe, "any_area(text(^\\s*/\\*\\s+SAF-[0-9]+-safe\\s+MC3R1\\.R7\\.4.*$, begin-1))"} > --doc_end > - > -doc_begin="Allow pointers of non-character type as long as the pointee is > const-qualified." > -config=MC3R1.R7.4,same_pointee=false > @@ -222,12 +213,6 @@ definition is compiled-out or optimized-out by the compiler)" > # Series 9. > # > > --doc_begin="The following variables are written before being set, therefore no > -access to uninitialized memory locations happens, as explained in the deviation > -comment." > --config=MC3R1.R9.1,reports+={safe, "any_area(text(^\\s*/\\*\\s+SAF-[0-9]+-safe\\s+MC3R1\\.R9\\.1.*$, begin-1))"} > --doc_end > - > -doc_begin="Violations in files that maintainers have asked to not modify in the > context of R9.1." > -file_tag+={adopted_r9_1,"^xen/arch/arm/arm64/lib/find_next_bit\\.c$"} > @@ -274,6 +259,14 @@ still non-negative." > -config=MC3R1.R10.1,etypes+={safe, "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))", "dst_type(ebool||boolean)"} > -doc_end > > +# > +# Series 11 > +# > + > +-doc_begin="This macro 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$))))"} > +-doc_end > + > ### Set 3 ### > > # > diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst > index 3139ca7ae6dd..d5569696b3a8 100644 > --- a/docs/misra/rules.rst > +++ b/docs/misra/rules.rst > @@ -393,7 +393,8 @@ maintainers if you want to suggest a change. > * - `Rule 11.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_09.c>`_ > - Required > - The macro NULL shall be the only permitted form of null pointer constant > - - > + - Using 0 as a null pointer constant to check if a type is scalar is > + allowed and always happens through the macro __ACCESS_ONCE. > > * - `Rule 12.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_12_05.c>`_ > - Mandatory > diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h > index dd99e573083f..15be9a750b23 100644 > --- a/xen/include/xen/compiler.h > +++ b/xen/include/xen/compiler.h > @@ -109,13 +109,16 @@ > > #define offsetof(a,b) __builtin_offsetof(a,b) > > +/* Access the field of structure type, without defining a local variable */ > +#define access_field(type, member) (((type *)NULL)->member) > +#define typeof_field(type, member) typeof(access_field(type, member)) > /** > * sizeof_field(TYPE, MEMBER) > * > * @TYPE: The structure containing the field of interest > * @MEMBER: The field to return the size of > */ > -#define sizeof_field(TYPE, MEMBER) sizeof((((TYPE *)0)->MEMBER)) > +#define sizeof_field(TYPE, MEMBER) sizeof(access_field(TYPE, MEMBER)) > > #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L > #define alignof __alignof__ > diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h > index 46b3c9c02625..2c5ed7736c99 100644 > --- a/xen/include/xen/kernel.h > +++ b/xen/include/xen/kernel.h > @@ -51,7 +51,7 @@ > * > */ > #define container_of(ptr, type, member) ({ \ > - typeof( ((type *)0)->member ) *__mptr = (ptr); \ > + typeof_field(type, member) *__mptr = (ptr); \ > (type *)( (char *)__mptr - offsetof(type,member) );}) > > /* > -- > 2.34.1 Cheers, [1] https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch_series.3F
On 06/10/2023 11:27, Julien Grall wrote: > Hi, > > On 05/10/2023 09:45, Nicola Vetrini wrote: >> The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a >> compile-time check to detect non-scalar types; its usage for this >> purpose is documented in rules.rst as an exception. > Documenting ACCESS_ONCE() in rules.rst seems a bit odd. I am guessing > that other analysis tool may point out the same error and therefore it > would seem more appropriate to use a deviation. > > This would also avoid having a specific rule in the Eclair > configuration for __ACCESS_ONCE(). > I figured a single accepted use would benefit from an explicit exclusion. I can rework it to use an in-code comment to deviate, in whatever form that comment may be (still with some bits of ECLAIR-specific configuration anyway, as discussed for R2.1). >> >> Furthermore, the 'access_field' and 'typeof_field' macros are >> introduced as a general way to deal with accesses to structs >> without declaring a struct variable. >> >> Cleanup of spurious MISRA deviations. > > Please don't do that. This is making the review of the patches a lot > more complicated because there are unrelated changes (see [1]). > > We often allow simple clean-up if they are in the context. But this is > not the case here. > Understood. There will be a separate MISRA deviations cleanup/update patch anyway, so these can be included there. > [1] > https://wiki.xenproject.org/wiki/Submitting_Xen_Project_Patches#What_is_in_a_patch_series.3F
On 06/10/2023 10:58, Nicola Vetrini wrote: > On 06/10/2023 11:27, Julien Grall wrote: >> Hi, >> >> On 05/10/2023 09:45, Nicola Vetrini wrote: >>> The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a >>> compile-time check to detect non-scalar types; its usage for this >>> purpose is documented in rules.rst as an exception. >> Documenting ACCESS_ONCE() in rules.rst seems a bit odd. I am guessing >> that other analysis tool may point out the same error and therefore it >> would seem more appropriate to use a deviation. >> >> This would also avoid having a specific rule in the Eclair >> configuration for __ACCESS_ONCE(). >> > > I figured a single accepted use would benefit from an explicit exclusion. > I can rework it to use an in-code comment to deviate, in whatever form > that comment may be > (still with some bits of ECLAIR-specific configuration anyway, as > discussed for R2.1). I think it would be preferrable to have a deviation in the code. This would be helpful for other analysis tools. > >>> >>> Furthermore, the 'access_field' and 'typeof_field' macros are >>> introduced as a general way to deal with accesses to structs >>> without declaring a struct variable. >>> >>> Cleanup of spurious MISRA deviations. >> >> Please don't do that. This is making the review of the patches a lot >> more complicated because there are unrelated changes (see [1]). >> >> We often allow simple clean-up if they are in the context. But this is >> not the case here. >> > > Understood. There will be a separate MISRA deviations cleanup/update > patch anyway, > so these can be included there. Sounds good to me. Thanks! Cheers,
On Fri, 6 Oct 2023, Julien Grall wrote: > On 06/10/2023 10:58, Nicola Vetrini wrote: > > On 06/10/2023 11:27, Julien Grall wrote: > > > Hi, > > > > > > On 05/10/2023 09:45, Nicola Vetrini wrote: > > > > The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a > > > > compile-time check to detect non-scalar types; its usage for this > > > > purpose is documented in rules.rst as an exception. > > > Documenting ACCESS_ONCE() in rules.rst seems a bit odd. I am guessing > > > that other analysis tool may point out the same error and therefore it > > > would seem more appropriate to use a deviation. > > > > > > This would also avoid having a specific rule in the Eclair > > > configuration for __ACCESS_ONCE(). > > > > > > > I figured a single accepted use would benefit from an explicit exclusion. > > I can rework it to use an in-code comment to deviate, in whatever form that > > comment may be > > (still with some bits of ECLAIR-specific configuration anyway, as discussed > > for R2.1). > > I think it would be preferrable to have a deviation in the code. This would be > helpful for other analysis tools. Yes exactly, see my reply: https://marc.info/?l=xen-devel&m=169663696228889 I know I acked the patch but I agree with Julien. A deviation as an in-code comment (SAF-x-safe) is always the best option. If that doesn't work, we cannot keep adding stuff in the notes section of rules.rst. It doesn't scale. We should create a new document, like deviations.rst, or add a new section at the bottom of documenting-violations.rst or possibly safe.json.
On 07/10/2023 02:33, Stefano Stabellini wrote: > On Fri, 6 Oct 2023, Julien Grall wrote: >> On 06/10/2023 10:58, Nicola Vetrini wrote: >> > On 06/10/2023 11:27, Julien Grall wrote: >> > > Hi, >> > > >> > > On 05/10/2023 09:45, Nicola Vetrini wrote: >> > > > The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a >> > > > compile-time check to detect non-scalar types; its usage for this >> > > > purpose is documented in rules.rst as an exception. >> > > Documenting ACCESS_ONCE() in rules.rst seems a bit odd. I am guessing >> > > that other analysis tool may point out the same error and therefore it >> > > would seem more appropriate to use a deviation. >> > > >> > > This would also avoid having a specific rule in the Eclair >> > > configuration for __ACCESS_ONCE(). >> > > >> > >> > I figured a single accepted use would benefit from an explicit exclusion. >> > I can rework it to use an in-code comment to deviate, in whatever form that >> > comment may be >> > (still with some bits of ECLAIR-specific configuration anyway, as discussed >> > for R2.1). >> >> I think it would be preferrable to have a deviation in the code. This >> would be >> helpful for other analysis tools. > > Yes exactly, see my reply: > https://marc.info/?l=xen-devel&m=169663696228889 > > I know I acked the patch but I agree with Julien. A deviation as an > in-code comment (SAF-x-safe) is always the best option. If that doesn't > work, we cannot keep adding stuff in the notes section of rules.rst. It > doesn't scale. We should create a new document, like deviations.rst, or > add a new section at the bottom of documenting-violations.rst or > possibly safe.json. I'll rebase this patch with an entry in deviations.rst, so that this applies to staging cleanly.
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl index d8170106b449..acd42386e0a9 100644 --- a/automation/eclair_analysis/ECLAIR/deviations.ecl +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl @@ -110,10 +110,6 @@ neither functions nor pointers to functions." -config=MC3R1.R5.5,reports={safe,"all_area(decl(node(enum_decl||record_decl||field_decl||param_decl||var_decl)&&!type(canonical(address((node(function||function_no_proto))))))||macro(function_like()))"} -doc_end --doc_begin="The use of these identifiers for both macro names and other entities -is deliberate and does not generate developer confusion." --config=MC3R1.R5.5,reports+={safe, "any_area(text(^\\s*/\\*\\s+SAF-[0-9]+-safe\\s+MC3R1\\.R5\\.5.*$, begin-1))"} --doc_end -doc_begin="The definition of macros and functions ending in '_bit' that use the same identifier in 'bitops.h' is deliberate and safe." @@ -156,11 +152,6 @@ particular use of it done in xen_mk_ulong." -config=MC3R1.R7.2,reports+={deliberate,"any_area(any_loc(macro(name(BUILD_BUG_ON))))"} -doc_end --doc_begin="The following string literals are assigned to pointers to non -const-qualified char." --config=MC3R1.R7.4,reports+={safe, "any_area(text(^\\s*/\\*\\s+SAF-[0-9]+-safe\\s+MC3R1\\.R7\\.4.*$, begin-1))"} --doc_end - -doc_begin="Allow pointers of non-character type as long as the pointee is const-qualified." -config=MC3R1.R7.4,same_pointee=false @@ -222,12 +213,6 @@ definition is compiled-out or optimized-out by the compiler)" # Series 9. # --doc_begin="The following variables are written before being set, therefore no -access to uninitialized memory locations happens, as explained in the deviation -comment." --config=MC3R1.R9.1,reports+={safe, "any_area(text(^\\s*/\\*\\s+SAF-[0-9]+-safe\\s+MC3R1\\.R9\\.1.*$, begin-1))"} --doc_end - -doc_begin="Violations in files that maintainers have asked to not modify in the context of R9.1." -file_tag+={adopted_r9_1,"^xen/arch/arm/arm64/lib/find_next_bit\\.c$"} @@ -274,6 +259,14 @@ still non-negative." -config=MC3R1.R10.1,etypes+={safe, "stmt(operator(logical)||node(conditional_operator||binary_conditional_operator))", "dst_type(ebool||boolean)"} -doc_end +# +# Series 11 +# + +-doc_begin="This macro 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$))))"} +-doc_end + ### Set 3 ### # diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst index 3139ca7ae6dd..d5569696b3a8 100644 --- a/docs/misra/rules.rst +++ b/docs/misra/rules.rst @@ -393,7 +393,8 @@ maintainers if you want to suggest a change. * - `Rule 11.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_09.c>`_ - Required - The macro NULL shall be the only permitted form of null pointer constant - - + - Using 0 as a null pointer constant to check if a type is scalar is + allowed and always happens through the macro __ACCESS_ONCE. * - `Rule 12.5 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_12_05.c>`_ - Mandatory diff --git a/xen/include/xen/compiler.h b/xen/include/xen/compiler.h index dd99e573083f..15be9a750b23 100644 --- a/xen/include/xen/compiler.h +++ b/xen/include/xen/compiler.h @@ -109,13 +109,16 @@ #define offsetof(a,b) __builtin_offsetof(a,b) +/* Access the field of structure type, without defining a local variable */ +#define access_field(type, member) (((type *)NULL)->member) +#define typeof_field(type, member) typeof(access_field(type, member)) /** * sizeof_field(TYPE, MEMBER) * * @TYPE: The structure containing the field of interest * @MEMBER: The field to return the size of */ -#define sizeof_field(TYPE, MEMBER) sizeof((((TYPE *)0)->MEMBER)) +#define sizeof_field(TYPE, MEMBER) sizeof(access_field(TYPE, MEMBER)) #if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L #define alignof __alignof__ diff --git a/xen/include/xen/kernel.h b/xen/include/xen/kernel.h index 46b3c9c02625..2c5ed7736c99 100644 --- a/xen/include/xen/kernel.h +++ b/xen/include/xen/kernel.h @@ -51,7 +51,7 @@ * */ #define container_of(ptr, type, member) ({ \ - typeof( ((type *)0)->member ) *__mptr = (ptr); \ + typeof_field(type, member) *__mptr = (ptr); \ (type *)( (char *)__mptr - offsetof(type,member) );}) /*
The constant 0 is used instead of NULL in '__ACCESS_ONCE' as a compile-time check to detect non-scalar types; its usage for this purpose is documented in rules.rst as an exception. Furthermore, the 'access_field' and 'typeof_field' macros are introduced as a general way to deal with accesses to structs without declaring a struct variable. Cleanup of spurious MISRA deviations. No functional change intended. Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> --- If NULL is not suitable for usage inside access_field, then 0 could be put there and the macro deviated. --- .../eclair_analysis/ECLAIR/deviations.ecl | 23 +++++++------------ docs/misra/rules.rst | 3 ++- xen/include/xen/compiler.h | 5 +++- xen/include/xen/kernel.h | 2 +- 4 files changed, 15 insertions(+), 18 deletions(-) -- 2.34.1