On 18.09.2022 15:02, Roberto Bagnara wrote:
> On 03/09/22 02:52, Stefano Stabellini wrote:
>> The question is on the interpretation of Rule 20.7. Are parenthesis
>> required by Rule 20.7 in the following cases:
>>
>> - macro parameters used as function arguments
> > [...]
> > - macro parameter used as lhs in assignment
>
> You can obtain different semantics depending on whether parentheses
> are or are not used (in the macro call and/or macro expansion
> depending on the case):
>
>
> #include <stdio.h>
>
> void g(int v) {
> printf("%d\n", v);
> }
>
> #define m1(x, y, ...) g(y)
>
> void f1(int x, int y, ...) {
> g(y);
> }
>
> #define p 0, 1
>
> void test1() {
> m1(p, 2);
> f1(p, 2);
> }
>
> #define m4(x) x = 4
>
> void f4(int &x) {
Let's focus on C here.
> x = 4;
> }
>
>
> void test4() {
> int y;
> int z;
> z = 3;
> m4(y = z);
> printf("%d\n", z);
> z = 3;
> f4(y = z);
> printf("%d\n", z);
> }
>
> int main() {
> test1();
> test4();
> }
>
>> - macro parameters used as macro arguments
>
> Please note that Rule 20.7 depends on the final expansion:
> so whether parentheses are or are not used in a certain
> macro body is irrelevant, the point being that, at the
> end of all expansions, expressions resulting from the
> expansion of macro parameters are enclosed in parentheses.
>
>> - macro parameter used as array index
>
> This is safe today, but my understanding is that in C++23
> the [] operator will accept more than one expression.
> A similar change might (who knows?) be considered for C26
> or even offered before (intentionally or by mistake) by some
> C compiler.
>
>> Some of these cases are interesting because they should function
>> correctly even without parenthesis, hence the discussion. In particular
>> parenthesis don't seem necessary at least for the function argument
>> case.
>
> This is not the right spirit for MISRA compliance: why would you want
> splitting hairs when inserting a pair of parentheses is so easy?
I think I've said so before - too many parentheses harm readability.
> C and C++ are very complex languages, and the MISRA coding standards
> are the result of a (very difficult!) compromise between simplicity
> and effectiveness: rules that are exactly targeted to all and only all
> the problematic instances would be very difficult to express and to remember.
> So, yes: in many cases you might spend time to demonstrate that a particular
> (real) MISRA violation does not imply the existence of a real issue,
> but this time is not well spent. Critical code must be boring and obviously
> right, in the sense that whomever is reading the code should not be
> distracted by thoughts like "there are no parentheses here: am I sure
> nothing bad can happen?"
I also did indicate before that "(x) = ..." visually (but not
syntactically) can raise the question of whether the left side actually
is an lvalue.
Jan
