how to fix brp and rpmlint warnings – today:
I: Program causes undefined operation
(likely same variable used twice and post/pre incremented in the same expression)

It seems the planned series sort of finds an audience, which in turn of course is motivational to keep on writing it. Today, we’ll have a look at this Informational message in BRP checks:

I: Program causes undefined operation
(likely same variable used twice and post/pre incremented in the same expression).
e.g. x = x++; Split it in two operations.

This is currently informational only and is not failing the build, but you might want to address them together with upstream.

I assume you do know what “a++” means in C (otherwise, you should start reading C-books), so we just try to reproduce this error in a simple c test case:
#include <stdio.h>

int main() {
int i=5;
i = i++ * ++i;
printf("The current value of i is %d\n", i);
return 0;
}

When building this using gcc -Wall test.c, we get this compiler warning (which in turn is what brp translates to the information we’re discussing here)

> gcc -Wall test2.c
test.c: In function ‘main’:
test.c:5:5: warning: operation on ‘i’ may be undefined

So, let’s first see for ourselves what we would expect this to be? Hmm.. already for us, this looks not logic (and I surely hope nobody would write this code).
Let’s just see what starting this executable gives shall we?

The current value of i is 37

Now, is this surprising? We multiplied, assigned it to i and as a result we get a prime number? By closely analyzing the line you will likely understand what the compiler did. But was this expected? If this is actually what the programmer intended, the code should just be rewritten to be more logical, like:
i = (i+1) ^2 + 1;
This is understandable for all of us and does not yield the surprise of what is going on.

And that is actually all this warning is about: it requests the programmer to write code that can be understood and does not depend on what the compiler interprets. It might even very well be that the different optimization levels or the usage of different compilers might end up in different results.

If you want to read some more about this topic, I suggest to have a look at:
Wikipedia
http://publications.gbdirect.co.uk/c_book/chapter8/sequence_points.html