On Mon, Feb 26, 2018 at 02:42:40PM -0600, Jason L Tibbitts III wrote: > >>>>> "JJ" == Jakub Jelinek <jakub@xxxxxxxxxx> writes: > > JJ> Ok, so the problem is ignoring important warnings, in this case: > JJ> imap/xapian_wrap.cpp: In function 'int > JJ> stem_version_set(Xapian::WritableDatabase*, int)': > JJ> imap/xapian_wrap.cpp:267:1: warning: no return statement in function > JJ> returning non-void [-Wreturn-type] > > OK, so good, that's bad upstream code. I have given good odds on this > being an upstream issue all along, but because the backtraces go through > the unwinder it seemed obvious to look there first. > > I do have to ask, though; is it considered good behavior to just > segfault like this? I understand that undefined behavior is just that, Yes. An optimizing compiler simply attempts to optimize, using assumption that a valid program doesn't invoke undefined behavior. If you don't care about performance and want these runtime bugs to be diagnosed, we have the sanitizers where it will be reported as a bug at runtime. > but it seems like there has to be a better way to fail that at least > looks like it's not a GCC bug. > > And, finally, if doing this in C++ code is so bad, why isn't this simply > an error? Because the warning could have false positives (some cases where the compiler can't prove no fallthrough to last line of function can happen and warns) and that nothing is actually wrong if either the function isn't called or whenever it is called takes a different path or throw an exception or similar. Compared to previous GCC versions, in C++ the warning is now emitted by default even without -Wreturn-type or -Wall. Jakub _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
