More dangerous UB handling of clang (compared to gcc)

[Dmitry Marakasov]

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.

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).

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'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.

-- 
Dmitry Marakasov   .   55B5 0596 FF1E 8D84 5F56  9510 D35A 80DD F9D2 F77D
amdmi3 at amdmi3.ru  ..:  jabber: amdmi3 at jabber.ru    http://www.amdmi3.ru