[opensuse-packaging] How to disable no-return-in-nonvoid-function?
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? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting Ilya Chernykh
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... Best regards, Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 26 November 2012 13:36:46 Dominique Leuenberger a.k.a 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 method. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting Ilya Chernykh
On Monday 26 November 2012 13:36:46 Dominique Leuenberger a.k.a 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 method.
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... Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ilya Chernykh
: On Monday 26 November 2012 13:36:46 Dominique Leuenberger a.k.a
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 method.
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. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting Ruediger Meier
On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ilya Chernykh
: On Monday 26 November 2012 13:36:46 Dominique Leuenberger a.k.a
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 method.
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) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting "Dominique Leuenberger a.k.a DimStar"
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; } ###
To make this code a bit less obvious, simply use: ### #include <iostream> int foo() { int a = 5; int b = a + 1; char* c = NULL; } int main() { std::cout << foo() << std::endl; } ### => the output of foo() is equal between the two... Dominique -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ruediger Meier
: On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ilya Chernykh
: On Monday 26 November 2012 13:36:46 Dominique Leuenberger a.k.a
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 method.
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.)
Best regards, Dominique (who wishes upstreams would learn about -Werror -Wall)
Yes, if you want to break your build on any compiler update. FYI https://lkml.org/lkml/2011/4/21/325 cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Quoting Ruediger Meier
On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ruediger Meier
: On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ilya Chernykh
: On Monday 26 November 2012 13:36:46 Dominique Leuenberger a.k.a
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 method.
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
On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ruediger Meier
: On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar wrote:
Quoting Ruediger Meier
: On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar
wrote:
Quoting Ilya Chernykh
: On Monday 26 November 2012 13:36:46 Dominique Leuenberger a.k.a
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 method.
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
int foo(int i) { if (i > 0) return 1; assert(0) }
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 warnings. cu, Rudi -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Ruediger Meier
On Monday 26 November 2012, Dominique Leuenberger a.k.a DimStar wrote:
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.)
Best regards, Dominique (who wishes upstreams would learn about -Werror -Wall)
Yes, if you want to break your build on any compiler update.
I find it generally useful to rebuild packages with clang or even scan-build when investigating compiler warnings. While it isn't completely without false positives, it is vastly better than gcc and its warnings are actually readable and give you some context often allowing you to issues or non-issues without even digging into the source files. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Ruediger Meier (sweet_f_a@gmx.de) [20121126 12:51]:
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.
It's a warning from the compiler but a build will fail if the pacakge checks will find these (and a few others) warnings. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 26 November 2012 13:52:56 Dominique Leuenberger a.k.a DimStar wrote:
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 method.
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...
No, it was in rpmlint for long tme. This allowed to selectively catch this error without disabling other checks (including incorrect return types). -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hi Ilya, * Ilya Chernykh (anixxsus@gmail.com) [20121126 10:24]:
I have a package that brings about 50 errors "no-return-in-nonvoid-function".
You once again fail to state the package URL so that others like me may have a look at the package.
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")
It is plain wrong to ignore this warning. You *have* to check each one closely to decide whether or not to fix it. That is also why a package maintainer should have a basic knowledge of the programming language a pckage is written in.
and also I am afraid this can break all the existing and future patches to this package.
I have never encountered a rejection by upstream when I sent patches fixing these warnings their way. But otherwise: welcome to the maintenance world, i.e., forward porting patches is part of a packagers work.
Previously I could disable it by setting the badness to 0 but it seems this does not work any more. What should I do?
Tell the package URL and let others try to fix the issue. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 26 November 2012 21:44:10 Philipp Thomas wrote:
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")
It is plain wrong to ignore this warning. You *have* to check each one closely to decide whether or not to fix it. That is also why a package maintainer should have a basic knowledge of the programming language a pckage is written in.
and also I am afraid this can break all the existing and future patches to this package.
I have never encountered a rejection by upstream when I sent patches fixing these warnings their way. But otherwise: welcome to the maintenance world, i.e., forward porting patches is part of a packagers work.
Previously I could disable it by setting the badness to 0 but it seems this does not work any more. What should I do?
Tell the package URL and let others try to fix the issue.
https://build.opensuse.org/package/show?package=kde3-kdenlive&project=KDE%3AKDE3 But even if built the program crashes upon start :-( -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
26 ноября 2012 23:17:05 Ilya Chernykh написал(а):
https://build.opensuse.org/package/show?package=kde3-kdenlive&project=KDE%3A KDE3
But even if built the program crashes upon start :-(
It's normal for old versions of kdenlive. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Ilya Chernykh (anixxsus@gmail.com) [20121126 20:23]:
https://build.opensuse.org/package/show?package=kde3-kdenlive&project=KDE%3AKDE3
When I build this for factory (i.e., the default), I get a number of warnings butg no 'missing return'. For which build do you get the warnings? Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wednesday 28 November 2012 22:15:29 Philipp Thomas wrote:
https://build.opensuse.org/package/show?package=kde3-kdenlive&project=KDE%3AKDE3
When I build this for factory (i.e., the default), I get a number of warnings butg no 'missing return'. For which build do you get the warnings?
As you can see from the spec file, the warning is disabled currently. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Ilya Chernykh (anixxsus@gmail.com) [20121128 20:09]:
As you can see from the spec file, the warning is disabled currently.
Yepp, found that a few seconds *after* I had posted the mail :( After passing %optflags in CXXFLAGS I get them. Will see if/when I can have a look at them. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (6)
-
Dmitry Roshchin
-
Dominique Leuenberger a.k.a DimStar
-
Guido Berhoerster
-
Ilya Chernykh
-
Philipp Thomas
-
Ruediger Meier