On Mar 1, 2014, at 4:18 PM, Ahmed Charles <[email protected]> wrote:
> ---------------------------------------- >> Subject: Re: More dangerous UB handling of clang (compared to gcc) >> From: [email protected] >> Date: Fri, 28 Feb 2014 08:38:38 -0700 >> To: [email protected] >> CC: [email protected] >> >> >> On Feb 28, 2014, at 8:06 AM, Dmitry Marakasov <[email protected]> wrote: >> >>> Hi! >>> >>> Another issue I wanted to mention: compared to gcc, clang handles >>> some undefined behaviour cases more dangerously. It has the full >>> right to do so as it's UB, however we may want to take extra steps >>> to find and fix these cases. >> >> Except this is a flat out bug…. >> >>> Example: >>> >>> --- ub.cc begins here --- >>> #include <iostream> >>> >>> int func1() { >>> std::cerr << "func1()\n"; >>> /* no return */ >>> } >>> >>> void func2() { >>> std::cerr << "NEVER CALLED\n"; >>> } >>> >>> int main() { >>> func1(); >>> return 0; >>> } >>> --- ub.cc ends here --- >>> >>> --- >>> % g++46 -o ub ub.cc && ./ub >>> func1() >>> % g++46 -O2 -o ub ub.cc && ./ub >>> func1() >>> % clang++ -o ub ub.cc && ./ub >>> ub.cc:6:1: warning: control reaches end of non-void function >>> [-Wreturn-type] >>> } >>> ^ >>> 1 warning generated. >>> func1() >>> Illegal instruction >>> % clang++ -O2 -o ub ub.cc && ./ub >>> ub.cc:6:1: warning: control reaches end of non-void function >>> [-Wreturn-type] >>> } >>> ^ >>> 1 warning generated. >>> func1() >>> NEVER CALLED >>> Segmentation fault >>> --- >>> >>> As you can see, while with gcc the function returns even if it has no >>> return statement, with clang it either crashes or calls the following >>> function. This may lead to new crashes and security problems after >>> switching to clang (most likely in ports code of course). >> >> This is a flat out bug. When control reaches the end of a function, it must >> return, even if there’s no return statement. The value returned from func1() >> is, of course, undefined, but this is well defined behavior in the standard… >> >> I’d be very interested to see chapter and verse on this one... > > n3690: 6.6.3[stmt.return]/p2 > > Flowing off the end of a function is equivalent to a return with no value; > this results in undefined behavior in a value-returning function. > > C++ and C are distinctly different in this regard. Seems like the ‘jump into the next function’ as a result of the core dump you put in being optimized away is a breathtakingly stupid, but allowed, undefined behavior. I mean, as stupid as forking rogue when #pragma is encountered. Better for that forced core dump to not be optimized away, or there be a return statement. Hence my belief that the resolution is bogus. >>> I wonder of we could make use of -Werror=return-type which makes the >>> warning issued by clang here fatal, what do you think? If adding it to >>> default CFLAGS/CXXFLAGS is not an option, we may at least have an >>> extra `strict' pkg-fallout builder. >>> >>> Related clang bug: http://llvm.org/bugs/show_bug.cgi?id=18296 (resoleved >>> as INVALID). >> >> I believe this resolution is, in fact, bogus. Sure, insert ud2, but also put >> a f’ing return in there. >> >> I know in C11,this id definitely the case: >> >> 6.9.1: >> 12 If the } that terminates a function is reached, and the value of the >> function call is used by >> the caller, the behavior is undefined. >> >> But the C++ standard is somewhat opaque on the topic, but none of the 56 >> instances of ‘undefined results’ in the standard appeared to apply. >> >>> I'm also positively sure that I've encountered another problematic >>> UB case with another warning, but I don't remember which. Real >>> list of useful Werror's may be quite big. >> >> Yea, this is a big deal. Sure, people shouldn’t do this, but this kind of >> undefined behavior is well outside the bounds of traditional compilers. >> >> Warner >> >> >> _______________________________________________ >> [email protected] mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to "[email protected]" >> > _______________________________________________ > [email protected] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "[email protected]" _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "[email protected]"
