[Bug c++/94768] Wreturn-type should be error, not warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94768 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=55189 Resolution|INVALID |DUPLICATE --- Comment #7 from Jonathan Wakely --- Dup of PR 43943 (and others) *** This bug has been marked as a duplicate of bug 43943 ***
[Bug c++/94768] Wreturn-type should be error, not warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94768 --- Comment #6 from Jonathan Wakely --- (In reply to David Binderman from comment #3) > Most of the time, it is in its own GNU mode and so could do a more > useful job here rather than IMHO blindly following non-useful standards. Nobody is "blindly following" anything. It's been discussed in detail by people who know what they're talking about, over many years (including again when -Wreturn-type was enabled by default for C++). Rejecting valid C++ code by default is not OK.
[Bug c++/94768] Wreturn-type should be error, not warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94768 --- Comment #5 from Andrew Pinski --- (In reply to David Binderman from comment #3) > I checked the source code of the popular Fedora Linux distribution. > There are 32 examples of this problem in the C++ code, so they will > need fixing. > > Interestingly, there are a whopping 258 examples in the C code, but that's a > separate issue. Note C and C++ have slightly different notice about "no return statement in function returning non-void"; In C it is only undefined if the return value is used while in C++ it is undefined the moment that the end of the function happens.
[Bug c++/94768] Wreturn-type should be error, not warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94768 --- Comment #4 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #1) > (In reply to David Binderman from comment #0) > > IMHO, for a C++ function returning non-void, a complete absence of any > > return statement in the function really should produce an error. > > This is a valid C++ program and it would be non-conforming to reject it. The > compiler can't even assume the program has undefined behaviour, because > g(int) could throw an exception, or do something that terminates, or simply > never return (e.g. go into an infinite loops with side effects like I/O). Just to expand on this. undefined at runtime behavior is not supposed to stop compilation of a translation unit.
[Bug c++/94768] Wreturn-type should be error, not warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94768 --- Comment #3 from David Binderman --- (In reply to Jonathan Wakely from comment #1) > This is a valid C++ program and it would be non-conforming to reject it. Surprising. The standard looks broken to me. Standards conformance only really matters if GNU C++ is in standards conformance mode. Most of the time, it is in its own GNU mode and so could do a more useful job here rather than IMHO blindly following non-useful standards. I checked the source code of the popular Fedora Linux distribution. There are 32 examples of this problem in the C++ code, so they will need fixing. Interestingly, there are a whopping 258 examples in the C code, but that's a separate issue.
[Bug c++/94768] Wreturn-type should be error, not warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94768 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > This is a valid C++ program s/program/translation unit/
[Bug c++/94768] Wreturn-type should be error, not warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94768 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- (In reply to David Binderman from comment #0) > IMHO, for a C++ function returning non-void, a complete absence of any > return statement in the function really should produce an error. This is a valid C++ program and it would be non-conforming to reject it. The compiler can't even assume the program has undefined behaviour, because g(int) could throw an exception, or do something that terminates, or simply never return (e.g. go into an infinite loops with side effects like I/O).
