| Message ID | 2bc4a964f0f2f47488e72237678e944dbdbd7bb7.1709219010.git.nicola.vetrini@bugseng.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | address some violations of MISRA C Rule 20.7 | expand |
On Thu, 29 Feb 2024, Nicola Vetrini wrote: > MISRA C Rule 20.7 states: "Expressions resulting from the expansion > of macro parameters shall be enclosed in parentheses". Therefore, some > macro definitions should gain additional parentheses to ensure that all > current and future users will be safe with respect to expansions that > can possibly alter the semantics of the passed-in macro parameter. > > No functional change. > > Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > --- > xen/common/keyhandler.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c > index 127ca506965c..4c1ce007870f 100644 > --- a/xen/common/keyhandler.c > +++ b/xen/common/keyhandler.c > @@ -42,10 +42,10 @@ static struct keyhandler { > } key_table[128] __read_mostly = > { > #define KEYHANDLER(k, f, desc, diag) \ > - [k] = { { .fn = (f) }, desc, 0, diag } > + [k] = { { .fn = (f) }, (desc), 0, (diag) } > > #define IRQ_KEYHANDLER(k, f, desc, diag) \ > - [k] = { { .irq_fn = (f) }, desc, 1, diag } > + [k] = { { .irq_fn = (f) }, (desc), 1, (diag) } > > IRQ_KEYHANDLER('A', do_toggle_alt_key, "toggle alternative key handling", 0), > IRQ_KEYHANDLER('d', dump_registers, "dump registers", 1), > -- > 2.34.1 >
On 29.02.2024 23:57, Stefano Stabellini wrote: > On Thu, 29 Feb 2024, Nicola Vetrini wrote: >> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >> of macro parameters shall be enclosed in parentheses". Therefore, some >> macro definitions should gain additional parentheses to ensure that all >> current and future users will be safe with respect to expansions that >> can possibly alter the semantics of the passed-in macro parameter. >> >> No functional change. >> >> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> > > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> You did see the discussion on earlier patches, though? I don't think any of the parentheses here are needed or wanted. Jan
On Fri, 1 Mar 2024, Jan Beulich wrote: > On 29.02.2024 23:57, Stefano Stabellini wrote: > > On Thu, 29 Feb 2024, Nicola Vetrini wrote: > >> MISRA C Rule 20.7 states: "Expressions resulting from the expansion > >> of macro parameters shall be enclosed in parentheses". Therefore, some > >> macro definitions should gain additional parentheses to ensure that all > >> current and future users will be safe with respect to expansions that > >> can possibly alter the semantics of the passed-in macro parameter. > >> > >> No functional change. > >> > >> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> > > > > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > > You did see the discussion on earlier patches, though? I don't think > any of the parentheses here are needed or wanted. We need to align on this. Currently if we go by what's written in docs/misra/deviations.rst, then rhs should have parentheses. Can we safely claim that rhs parentheses are never needed? If so, then great, let's add it to deviations.rst and skip them here and other places in this patch series (e.g. patch #8). When I say "never" I am taking for granted that the caller is not doing something completely unacceptably broken such as: WRITE_SYSREG64(var +, TTBR0_EL1) If we cannot generically claim that rhs parentheses are never needed, then I don't think we should make any exceptions. We should add them here and everywhere else. It should be easy to write a macro or review a patch with a macro from someone else, and making special exception makes it more difficult for everyone.
On 02.03.2024 02:37, Stefano Stabellini wrote: > On Fri, 1 Mar 2024, Jan Beulich wrote: >> On 29.02.2024 23:57, Stefano Stabellini wrote: >>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: >>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >>>> of macro parameters shall be enclosed in parentheses". Therefore, some >>>> macro definitions should gain additional parentheses to ensure that all >>>> current and future users will be safe with respect to expansions that >>>> can possibly alter the semantics of the passed-in macro parameter. >>>> >>>> No functional change. >>>> >>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> >>> >>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> >> >> You did see the discussion on earlier patches, though? I don't think >> any of the parentheses here are needed or wanted. > > We need to align on this. Currently if we go by what's written in > docs/misra/deviations.rst, then rhs should have parentheses. Quoting the actual patch again: --- a/xen/common/keyhandler.c +++ b/xen/common/keyhandler.c @@ -42,10 +42,10 @@ static struct keyhandler { } key_table[128] __read_mostly = { #define KEYHANDLER(k, f, desc, diag) \ - [k] = { { .fn = (f) }, desc, 0, diag } + [k] = { { .fn = (f) }, (desc), 0, (diag) } #define IRQ_KEYHANDLER(k, f, desc, diag) \ - [k] = { { .irq_fn = (f) }, desc, 1, diag } + [k] = { { .irq_fn = (f) }, (desc), 1, (diag) } What rhs are you talking about in light of this change? The only rhs I can spot here is already parenthesized. > Can we safely claim that rhs parentheses are never needed? If so, then > great, let's add it to deviations.rst and skip them here and other > places in this patch series (e.g. patch #8). When I say "never" I am > taking for granted that the caller is not doing something completely > unacceptably broken such as: > > WRITE_SYSREG64(var +, TTBR0_EL1) I'm afraid I can't associate this with the patch here either. Instead in the context here a (respective) construct as you mention above would simply fail to build. Jan > If we cannot generically claim that rhs parentheses are never needed, > then I don't think we should make any exceptions. We should add them here > and everywhere else. It should be easy to write a macro or review a > patch with a macro from someone else, and making special exception makes > it more difficult for everyone.
On Mon, 4 Mar 2024, Jan Beulich wrote: > On 02.03.2024 02:37, Stefano Stabellini wrote: > > On Fri, 1 Mar 2024, Jan Beulich wrote: > >> On 29.02.2024 23:57, Stefano Stabellini wrote: > >>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: > >>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion > >>>> of macro parameters shall be enclosed in parentheses". Therefore, some > >>>> macro definitions should gain additional parentheses to ensure that all > >>>> current and future users will be safe with respect to expansions that > >>>> can possibly alter the semantics of the passed-in macro parameter. > >>>> > >>>> No functional change. > >>>> > >>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> > >>> > >>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > >> > >> You did see the discussion on earlier patches, though? I don't think > >> any of the parentheses here are needed or wanted. > > > > We need to align on this. Currently if we go by what's written in > > docs/misra/deviations.rst, then rhs should have parentheses. > > Quoting the actual patch again: [...] > What rhs are you talking about in light of this change? The only rhs I > can spot here is already parenthesized. Yes you are right. I replied here as an overall comment about our approach to 20.7, although this patch is not a good example. My reply was meant in the context of https://marc.info/?l=xen-devel&m=170928051025701 > > Can we safely claim that rhs parentheses are never needed? If so, then > > great, let's add it to deviations.rst and skip them here and other > > places in this patch series (e.g. patch #8). When I say "never" I am > > taking for granted that the caller is not doing something completely > > unacceptably broken such as: > > > > WRITE_SYSREG64(var +, TTBR0_EL1) > > I'm afraid I can't associate this with the patch here either. Instead in > the context here a (respective) construct as you mention above would simply > fail to build. Fair enough it will break the build. I was trying to clarify that when I wrote "the rhs parentheses are never needed" I meant "never" within reason. One can always find ways to break the system and I tried to make an example of something that for sure would break rhs or lhs without parentheses. I meant to say, if we don't account for exceptionally broken cases, can we safety say we don't need parentheses for rhs? > > If we cannot generically claim that rhs parentheses are never needed, > > then I don't think we should make any exceptions. We should add them here > > and everywhere else. It should be easy to write a macro or review a > > patch with a macro from someone else, and making special exception makes > > it more difficult for everyone.
On 05.03.2024 03:03, Stefano Stabellini wrote: > On Mon, 4 Mar 2024, Jan Beulich wrote: >> On 02.03.2024 02:37, Stefano Stabellini wrote: >>> On Fri, 1 Mar 2024, Jan Beulich wrote: >>>> On 29.02.2024 23:57, Stefano Stabellini wrote: >>>>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: >>>>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >>>>>> of macro parameters shall be enclosed in parentheses". Therefore, some >>>>>> macro definitions should gain additional parentheses to ensure that all >>>>>> current and future users will be safe with respect to expansions that >>>>>> can possibly alter the semantics of the passed-in macro parameter. >>>>>> >>>>>> No functional change. >>>>>> >>>>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> >>>>> >>>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> >>>> >>>> You did see the discussion on earlier patches, though? I don't think >>>> any of the parentheses here are needed or wanted. >>> >>> We need to align on this. Currently if we go by what's written in >>> docs/misra/deviations.rst, then rhs should have parentheses. >> >> Quoting the actual patch again: > > [...] > >> What rhs are you talking about in light of this change? The only rhs I >> can spot here is already parenthesized. > > Yes you are right. I replied here as an overall comment about our > approach to 20.7, although this patch is not a good example. My reply > was meant in the context of https://marc.info/?l=xen-devel&m=170928051025701 I'm still confused: The rhs is being parenthsized there. It's the _lhs_ which isn't and ... >>> Can we safely claim that rhs parentheses are never needed? If so, then >>> great, let's add it to deviations.rst and skip them here and other >>> places in this patch series (e.g. patch #8). When I say "never" I am >>> taking for granted that the caller is not doing something completely >>> unacceptably broken such as: >>> >>> WRITE_SYSREG64(var +, TTBR0_EL1) >> >> I'm afraid I can't associate this with the patch here either. Instead in >> the context here a (respective) construct as you mention above would simply >> fail to build. > > Fair enough it will break the build. I was trying to clarify that when I > wrote "the rhs parentheses are never needed" I meant "never" within > reason. One can always find ways to break the system and I tried to make > an example of something that for sure would break rhs or lhs without > parentheses. > > I meant to say, if we don't account for exceptionally broken cases, can > we safety say we don't need parentheses for rhs? ... doesn't need to, unless - as you say - one contrives examples. Yet to clarify here as well: I assume you mean "we don't need parentheses for lhs". And note that even if your example used the first parameter as lhs of an assignment, the build would still break. The + there would not magically combine with the = to a += operator. Tokenization occurs ahead of preprocessing, so the expanded macro would still have a + token followed by a = one. The only way to alter tokens is by using the ## operator. Which in turn precludes using parentheses. Jan
On Tue, 5 Mar 2024, Jan Beulich wrote: > On 05.03.2024 03:03, Stefano Stabellini wrote: > > On Mon, 4 Mar 2024, Jan Beulich wrote: > >> On 02.03.2024 02:37, Stefano Stabellini wrote: > >>> On Fri, 1 Mar 2024, Jan Beulich wrote: > >>>> On 29.02.2024 23:57, Stefano Stabellini wrote: > >>>>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: > >>>>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion > >>>>>> of macro parameters shall be enclosed in parentheses". Therefore, some > >>>>>> macro definitions should gain additional parentheses to ensure that all > >>>>>> current and future users will be safe with respect to expansions that > >>>>>> can possibly alter the semantics of the passed-in macro parameter. > >>>>>> > >>>>>> No functional change. > >>>>>> > >>>>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> > >>>>> > >>>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > >>>> > >>>> You did see the discussion on earlier patches, though? I don't think > >>>> any of the parentheses here are needed or wanted. > >>> > >>> We need to align on this. Currently if we go by what's written in > >>> docs/misra/deviations.rst, then rhs should have parentheses. > >> > >> Quoting the actual patch again: > > > > [...] > > > >> What rhs are you talking about in light of this change? The only rhs I > >> can spot here is already parenthesized. > > > > Yes you are right. I replied here as an overall comment about our > > approach to 20.7, although this patch is not a good example. My reply > > was meant in the context of https://marc.info/?l=xen-devel&m=170928051025701 > > I'm still confused: The rhs is being parenthsized there. It's the _lhs_ > which isn't and ... > > >>> Can we safely claim that rhs parentheses are never needed? If so, then > >>> great, let's add it to deviations.rst and skip them here and other > >>> places in this patch series (e.g. patch #8). When I say "never" I am > >>> taking for granted that the caller is not doing something completely > >>> unacceptably broken such as: > >>> > >>> WRITE_SYSREG64(var +, TTBR0_EL1) > >> > >> I'm afraid I can't associate this with the patch here either. Instead in > >> the context here a (respective) construct as you mention above would simply > >> fail to build. > > > > Fair enough it will break the build. I was trying to clarify that when I > > wrote "the rhs parentheses are never needed" I meant "never" within > > reason. One can always find ways to break the system and I tried to make > > an example of something that for sure would break rhs or lhs without > > parentheses. > > > > I meant to say, if we don't account for exceptionally broken cases, can > > we safety say we don't need parentheses for rhs? > > ... doesn't need to, unless - as you say - one contrives examples. Yet to > clarify here as well: I assume you mean "we don't need parentheses for lhs". Yes. Far clarity, we are all aligned that lhs does not need parentheses and in fact it is even already deviated in docs/misra/deviations.rst. Now back to this specific patch. The problem is that the comma ',' doesn't need parenthesis for the parameters. However, the way we wrote the deviation in docs/misra/deviations.rst doesn't cover the case this patch is dealing with. docs/misra/deviations.rst only speaks of functions and macros arguments. Should we rephrase docs/misra/deviations.rst in terms of ',' instead ? Can ECLAR deal with it? > And note that even if your example used the first parameter as lhs of an > assignment, the build would still break. The + there would not magically > combine with the = to a += operator. Tokenization occurs ahead of > preprocessing, so the expanded macro would still have a + token followed by > a = one. The only way to alter tokens is by using the ## operator. Which in > turn precludes using parentheses. OK
On 07.03.2024 02:39, Stefano Stabellini wrote: > On Tue, 5 Mar 2024, Jan Beulich wrote: >> On 05.03.2024 03:03, Stefano Stabellini wrote: >>> On Mon, 4 Mar 2024, Jan Beulich wrote: >>>> On 02.03.2024 02:37, Stefano Stabellini wrote: >>>>> On Fri, 1 Mar 2024, Jan Beulich wrote: >>>>>> On 29.02.2024 23:57, Stefano Stabellini wrote: >>>>>>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: >>>>>>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion >>>>>>>> of macro parameters shall be enclosed in parentheses". Therefore, some >>>>>>>> macro definitions should gain additional parentheses to ensure that all >>>>>>>> current and future users will be safe with respect to expansions that >>>>>>>> can possibly alter the semantics of the passed-in macro parameter. >>>>>>>> >>>>>>>> No functional change. >>>>>>>> >>>>>>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> >>>>>>> >>>>>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> >>>>>> >>>>>> You did see the discussion on earlier patches, though? I don't think >>>>>> any of the parentheses here are needed or wanted. >>>>> >>>>> We need to align on this. Currently if we go by what's written in >>>>> docs/misra/deviations.rst, then rhs should have parentheses. >>>> >>>> Quoting the actual patch again: >>> >>> [...] >>> >>>> What rhs are you talking about in light of this change? The only rhs I >>>> can spot here is already parenthesized. >>> >>> Yes you are right. I replied here as an overall comment about our >>> approach to 20.7, although this patch is not a good example. My reply >>> was meant in the context of https://marc.info/?l=xen-devel&m=170928051025701 >> >> I'm still confused: The rhs is being parenthsized there. It's the _lhs_ >> which isn't and ... >> >>>>> Can we safely claim that rhs parentheses are never needed? If so, then >>>>> great, let's add it to deviations.rst and skip them here and other >>>>> places in this patch series (e.g. patch #8). When I say "never" I am >>>>> taking for granted that the caller is not doing something completely >>>>> unacceptably broken such as: >>>>> >>>>> WRITE_SYSREG64(var +, TTBR0_EL1) >>>> >>>> I'm afraid I can't associate this with the patch here either. Instead in >>>> the context here a (respective) construct as you mention above would simply >>>> fail to build. >>> >>> Fair enough it will break the build. I was trying to clarify that when I >>> wrote "the rhs parentheses are never needed" I meant "never" within >>> reason. One can always find ways to break the system and I tried to make >>> an example of something that for sure would break rhs or lhs without >>> parentheses. >>> >>> I meant to say, if we don't account for exceptionally broken cases, can >>> we safety say we don't need parentheses for rhs? >> >> ... doesn't need to, unless - as you say - one contrives examples. Yet to >> clarify here as well: I assume you mean "we don't need parentheses for lhs". > > Yes. Far clarity, we are all aligned that lhs does not need parentheses > and in fact it is even already deviated in docs/misra/deviations.rst. > > Now back to this specific patch. > > The problem is that the comma ',' doesn't need parenthesis for the > parameters. However, the way we wrote the deviation in > docs/misra/deviations.rst doesn't cover the case this patch is dealing > with. docs/misra/deviations.rst only speaks of functions and macros > arguments. > > Should we rephrase docs/misra/deviations.rst in terms of ',' instead ? That's what I've requested elsewhere, yes. > Can ECLAR deal with it? I seem to vaguely recall Nicola saying it can, but if not then it surely can be made to do so. Jan
On 2024-03-07 08:42, Jan Beulich wrote: > On 07.03.2024 02:39, Stefano Stabellini wrote: >> On Tue, 5 Mar 2024, Jan Beulich wrote: >>> On 05.03.2024 03:03, Stefano Stabellini wrote: >>>> On Mon, 4 Mar 2024, Jan Beulich wrote: >>>>> On 02.03.2024 02:37, Stefano Stabellini wrote: >>>>>> On Fri, 1 Mar 2024, Jan Beulich wrote: >>>>>>> On 29.02.2024 23:57, Stefano Stabellini wrote: >>>>>>>> On Thu, 29 Feb 2024, Nicola Vetrini wrote: >>>>>>>>> MISRA C Rule 20.7 states: "Expressions resulting from the >>>>>>>>> expansion >>>>>>>>> of macro parameters shall be enclosed in parentheses". >>>>>>>>> Therefore, some >>>>>>>>> macro definitions should gain additional parentheses to ensure >>>>>>>>> that all >>>>>>>>> current and future users will be safe with respect to >>>>>>>>> expansions that >>>>>>>>> can possibly alter the semantics of the passed-in macro >>>>>>>>> parameter. >>>>>>>>> >>>>>>>>> No functional change. >>>>>>>>> >>>>>>>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> >>>>>>>> >>>>>>>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> >>>>>>> >>>>>>> You did see the discussion on earlier patches, though? I don't >>>>>>> think >>>>>>> any of the parentheses here are needed or wanted. >>>>>> >>>>>> We need to align on this. Currently if we go by what's written in >>>>>> docs/misra/deviations.rst, then rhs should have parentheses. >>>>> >>>>> Quoting the actual patch again: >>>> >>>> [...] >>>> >>>>> What rhs are you talking about in light of this change? The only >>>>> rhs I >>>>> can spot here is already parenthesized. >>>> >>>> Yes you are right. I replied here as an overall comment about our >>>> approach to 20.7, although this patch is not a good example. My >>>> reply >>>> was meant in the context of >>>> https://marc.info/?l=xen-devel&m=170928051025701 >>> >>> I'm still confused: The rhs is being parenthsized there. It's the >>> _lhs_ >>> which isn't and ... >>> >>>>>> Can we safely claim that rhs parentheses are never needed? If so, >>>>>> then >>>>>> great, let's add it to deviations.rst and skip them here and other >>>>>> places in this patch series (e.g. patch #8). When I say "never" I >>>>>> am >>>>>> taking for granted that the caller is not doing something >>>>>> completely >>>>>> unacceptably broken such as: >>>>>> >>>>>> WRITE_SYSREG64(var +, TTBR0_EL1) >>>>> >>>>> I'm afraid I can't associate this with the patch here either. >>>>> Instead in >>>>> the context here a (respective) construct as you mention above >>>>> would simply >>>>> fail to build. >>>> >>>> Fair enough it will break the build. I was trying to clarify that >>>> when I >>>> wrote "the rhs parentheses are never needed" I meant "never" within >>>> reason. One can always find ways to break the system and I tried to >>>> make >>>> an example of something that for sure would break rhs or lhs without >>>> parentheses. >>>> >>>> I meant to say, if we don't account for exceptionally broken cases, >>>> can >>>> we safety say we don't need parentheses for rhs? >>> >>> ... doesn't need to, unless - as you say - one contrives examples. >>> Yet to >>> clarify here as well: I assume you mean "we don't need parentheses >>> for lhs". >> >> Yes. Far clarity, we are all aligned that lhs does not need >> parentheses >> and in fact it is even already deviated in docs/misra/deviations.rst. >> >> Now back to this specific patch. >> >> The problem is that the comma ',' doesn't need parenthesis for the >> parameters. However, the way we wrote the deviation in >> docs/misra/deviations.rst doesn't cover the case this patch is dealing >> with. docs/misra/deviations.rst only speaks of functions and macros >> arguments. >> >> Should we rephrase docs/misra/deviations.rst in terms of ',' instead ? > > That's what I've requested elsewhere, yes. > >> Can ECLAR deal with it? > > I seem to vaguely recall Nicola saying it can, but if not then it > surely > can be made to do so. > > Jan Yes. In v2 I'll write the deviation, so that this patch and other can be dropped, since they only deal with this subcase.
diff --git a/xen/common/keyhandler.c b/xen/common/keyhandler.c index 127ca506965c..4c1ce007870f 100644 --- a/xen/common/keyhandler.c +++ b/xen/common/keyhandler.c @@ -42,10 +42,10 @@ static struct keyhandler { } key_table[128] __read_mostly = { #define KEYHANDLER(k, f, desc, diag) \ - [k] = { { .fn = (f) }, desc, 0, diag } + [k] = { { .fn = (f) }, (desc), 0, (diag) } #define IRQ_KEYHANDLER(k, f, desc, diag) \ - [k] = { { .irq_fn = (f) }, desc, 1, diag } + [k] = { { .irq_fn = (f) }, (desc), 1, (diag) } IRQ_KEYHANDLER('A', do_toggle_alt_key, "toggle alternative key handling", 0), IRQ_KEYHANDLER('d', dump_registers, "dump registers", 1),
MISRA C Rule 20.7 states: "Expressions resulting from the expansion of macro parameters shall be enclosed in parentheses". Therefore, some macro definitions should gain additional parentheses to ensure that all current and future users will be safe with respect to expansions that can possibly alter the semantics of the passed-in macro parameter. No functional change. Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com> --- xen/common/keyhandler.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)