From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 28 15:07:01 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F4D46C7 for ; Fri, 28 Feb 2014 15:07:01 +0000 (UTC) Received: from smtpout6.timeweb.ru (smtpout6.timeweb.ru [92.53.117.39]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 579141564 for ; Fri, 28 Feb 2014 15:07:00 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1WJP1W-0006Uz-Ju for freebsd-toolchain@FreeBSD.org; Fri, 28 Feb 2014 19:06:50 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 409517E6 for ; Fri, 28 Feb 2014 19:06:50 +0400 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id 331EB246A; Fri, 28 Feb 2014 19:06:50 +0400 (MSK) Date: Fri, 28 Feb 2014 19:06:50 +0400 From: Dmitry Marakasov To: freebsd-toolchain@FreeBSD.org Subject: More dangerous UB handling of clang (compared to gcc) Message-ID: <20140228150650.GE29171@hades.panopticon> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 15:07:01 -0000 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 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@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru