Mailinglist Archive: opensuse-packaging (266 mails)

< Previous Next >
Re: [opensuse-packaging] How to disable no-return-in-nonvoid-function?
On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ruediger Meier <sweet_f_a@xxxxxx>:
On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar
Quoting Ruediger Meier <sweet_f_a@xxxxxx>:
On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar

Quoting Ilya Chernykh <anixxsus@xxxxxxxxx>:
On Monday 26 November 2012 13:36:46 Dominique Leuenberger

DimStar wrote:
I have a package that brings about 50 errors
"no-return-in-nonvoid-function". It is very difficult to
fix all these cases (not to mention I do not know C++ and
can only guess where to insert "0" and where "NULL")
and also I am afraid this can break all the existing and
future patches to this package. Previously I could disable
it by setting the badness
to 0 but it seems this does not work any more. What should
I do?

You should contact upstream and fix the issues...

If you really 'must' disable this (there is no chance for
the package to enter Factory though!) you can add
#!BuildIgnore: brp-check-suse
to the .spec file...

I know I can buildrequire -post-build-checks (was this
package renamed?), but this
will disable all ckecks. I want other checks in place, but
only this one removed (why it was transferred from
rpmlint to brp by the way?). Currently I added
"-Wno-return-type" to the compiller command line, but this
still seems to be too broad. Still looking for more specific

The most specific one is: patch the source and fix the
underlying issue. The no-return-in-nonvoid has been a brp check
for as long as I remember...

Best thing is really: bring it to upstream to get a proper fix
to it...

But don't forget that "no-return-in-nonvoid" is just a warning
and not an error. In many cases you can safely ignore it.

A warning by the compiler does not mean you don't have to care for
it.. It means the programmer is responsible to know what is
happening in this code and there is NO guarantee between gcc
versions that this is not 'just changing'.

The only valid solution is to fix the code.

See for example this code piece (C++)

#include <iostream>

int foo() {
int a = 5;
int b = a + 1;

int main() { std::cout << foo() << std::endl; }

What is the recommended output of this? this example is somewhat
simple enough to understand what is going on... BUT the bad thing
is, if you ever extend the function foo() with anything AFTER, you
migh get a new return value, which is not what you wanted... hence
the warning.

Best regards,
Dominique (who wishes upstreams would learn about -Werror -Wall)

The example below also gives you "control reaches end of non-void
function" and obviously the compiler (gcc 4.5.1) is wrong. A valid
solution here is to ignore the warning or to fix gcc.

int main()
int i = 1;
if (i == 1) {
return 1;

(This is a stupid trivial example. You can imagine that there are
also real world examples where the programmer knows for sure that
the warning is invalid.)

Right.. so both our examples show: it's not just 'sane to ignore' the
warning but the programmer better knows what he does and is conscious
about it... I'd come across MANY of those errors were the programmer
simply was not aware of side effects... often it is expected that the
return value be 0 in this case (which, by the way, is a valid
assumption for int main() {})

btw, another common case for this error is:

#include <assert.h>

int foo(int i) {
if (i > 0)
return 1;

Now, arguably, you can say the end is never reached... and the
compiler is just annoying... yt, the compiler can't know...

but if I use gcc -DNDEBUG, then the compiler is right...

I do not agree. The fact that the programmer placed an assert here means
that he carefully thought about it. It would be a bug somewhere else in
case it would be violated nevertheless.

But see a real world example in package devel:libraries:c_c++/hdf5
Most of the fixes in hdf5-non_void_return.patch are non-sense (just to
avoid the false warning). Upstream would not accept this patch for
sure. Note that probably the hdf5 guys don't even use gcc as primary
target compiler and other compilers may be more smart with their

To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-packaging+owner@xxxxxxxxxxxx

< Previous Next >