More dangerous UB handling of clang (compared to gcc)

[Warner Losh]

On Mar 1, 2014, at 4:18 PM, Ahmed Charles <acharles at outlook.com> wrote:

> ----------------------------------------
>> Subject: Re: More dangerous UB handling of clang (compared to gcc)
>> From: bsdimp at gmail.com
>> Date: Fri, 28 Feb 2014 08:38:38 -0700
>> To: amdmi3 at amdmi3.ru
>> CC: freebsd-toolchain at FreeBSD.org
>> 
>> 
>> On Feb 28, 2014, at 8:06 AM, Dmitry Marakasov <amdmi3 at amdmi3.ru> 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
>> 
>> 
>> _______________________________________________
>> freebsd-toolchain at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
>> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe at freebsd.org" 		 	   		  
> _______________________________________________
> freebsd-toolchain at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe at freebsd.org"