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

how to fix brp and rpmlint warnings – today:
Expression compares a char* pointer with a string literal

After having seen this kind of question several times, I think it could be interesting to start creating a small ‘series of rpmlint errors and their typical fixes”.

Interested in it? So welcome to part #1 (this issue). The “series” is not really fledged out, but I will try to write post for various errors / topics, as they come along. Just drop me a note with an error you have seen / experienced in OBS while building a package.

So what does it mean, if OBS tells you this:
Expression compares a char* pointer with a string literal. Usually a strcmp() was intended by the programmer

Let’s have a look at a very simple C program, to show the issue:
#include <stdio.h>

int main() {
char *mytext;
mytext = "Help";
if (mytext == "Help") {
printf("This should raise a warning");
}
return 0;
}Trying to compile this very simple C program, which on first sight many would probably say this is correct, will result in this:

$ gcc test1.c -Wall
test1.c: In function ‘main’:
test1.c:6:14: warning: comparison with string literal results in unspecified behavior

So, even though we had such an easy program, line 6 seems to be an issue for us:

if (mytext == “Help”) {

The issue, as simple as it may sound, is the comparison of a pointer (char *) with a literal (“Help”).

So how do we fix it? It involves changing the code, thus writing a patch (there are many good helps around for this… I won’t dive into patching here).. Of course, after having written a patch, be a good downstream, send it upstream!
What you want to do here is to replace this comparison with strcmp (just as OBS’ error message implied).
Look at this code now:
#include <stdio.h>
#include <string.h>

int main() {
char *mytext;
mytext = "Help";
if (strcmp(mytext,"Help")==0) {
printf("No warning here\n");
}
return 0;
}I changed “mytext == “Help” to strcmp(mtext,”Help”)==0 (man 3 strcmp will explain you why… 0 means the texts are equal, or ’0 difference detected’ can help you remember that). As the code was too simple and strcmp was not yet defined (this of course can also happen in packages you patch), I had to add an additional #include <string.h>.

Not too hard, is it?

So what do you think? Such a series of “how to fix my typical brp / lint warnings” useful?