[opensuse-buildservice] no-return-in-nonvoid-function not always true
Hi there, the error message of rpmlint no-return-in-nonvoid-function sometimes detects code snippets that looks ok to me. The code snippets moslty looks like this: ------ int func(int i) { switch(i) { case 1: return 4; case 2: return 5; } /* no return after switch statement */ } Example build logs: https://build.opensuse.org/package/live_build_log?arch=x86_64&package=freehdl&project=science&repository=openSUSE_11.1 https://build.opensuse.org/package/live_build_log?arch=x86_64&package=glemon&project=science&repository=openSUSE_11.1 Any chances to ignore those errors? In the thread http://lists.opensuse.org/opensuse-buildservice/2008-11/msg00146.html in the message http://lists.opensuse.org/opensuse-buildservice/2008-11/msg00156.html Bernhard Walle suggest to make that errors ignorable. What's the "right" solution to resolve those rpmlint errors? * fixing all that errors? * upstream reporting? Regards Werner (werner2101) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
Hi, Werner Hoch schrieb:
Hi there,
the error message of rpmlint no-return-in-nonvoid-function sometimes detects code snippets that looks ok to me.
The code snippets moslty looks like this: ------ int func(int i) { switch(i) { case 1: return 4; case 2: return 5; } /* no return after switch statement */ }
Hmm, that's not quite ok IMHO. What happens if i is not 1 or 2? You return random data, don't you?
What's the "right" solution to resolve those rpmlint errors? * fixing all that errors? * upstream reporting?
The right solution is to get them fixed either by reporting upstream or doing yourself and upstreaming then ;-) To get packages you probably can ignore them by rpmlint magic short term. Wolfgang -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Thu, 18 Dec 2008 08:25:22 +0100, you wrote:
int func(int i) { switch(i) { case 1: return 4; case 2: return 5; } /* no return after switch statement */ }
From a compilers POV this isn't OK. The compiler can't know that all possible values of i have been handled, so it must assume that there's a possibility that the end end of the function is reached and so warns of the missing return. Philipp -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
* Werner Hoch [2008-12-18 08:25]:
Bernhard Walle suggest to make that errors ignorable.
That was a different story. In you case the code is just wrong. Nobody can guarantee that you call the function with !(i == 1 || i == 2). Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
On Donnerstag, 18. Dezember 2008, Bernhard Walle wrote:
* Werner Hoch [2008-12-18 08:25]:
Bernhard Walle suggest to make that errors ignorable.
That was a different story. In you case the code is just wrong. Nobody can guarantee that you call the function with !(i == 1 || i == 2).
Sorry for my poor example, here's a better one where I can guarantee that it's ok. ---------------- #include <stdio.h> int testfunc(unsigned int i) { switch (i%2) { case 0: return 2; case 1: return 5; } } int main(void) { printf("%d, %d\n", 5, testfunc(5)); printf("%d, %d\n", 4, testfunc(4)); return 0; } ---------------- compiler output: -------- werner@linux-m82i:~/puffer> gcc -Wall main.c main.c: In function ‘testfunc’: main.c:11: warning: control reaches end of non-void function werner@linux-m82i:~/puffer> ./a.out 5, 5 4, 2 werner@linux-m82i:~/puffer> ------- I know that a default statement could fix the compiler warning. ---------- switch (i%2) { case 0: return 2; case 1: return 5; default: /* never reached */ return 5; } ---------- I'd just prefer to disable the check in such cases without patching all the code. Regards Werner -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
* Werner Hoch [2008-12-18 11:51]:
I'd just prefer to disable the check in such cases without patching all the code.
ACK. Warnings are warnings because the compiler cannot be 100 % right. If you 'work around' such warnings by adding 'default' should be an upstream decision and not a packaging decision. I usually do in my code. Bernhard -- Bernhard Walle, SUSE Linux Products GmbH, Architecture Development -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (4)
-
Bernhard Walle -
Philipp Thomas -
Werner Hoch -
Wolfgang Rosenauer