From owner-freebsd-toolchain@FreeBSD.ORG Sun Mar 2 16:31:32 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 72DFF5EF for ; Sun, 2 Mar 2014 16:31:32 +0000 (UTC) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 32975116D for ; Sun, 2 Mar 2014 16:31:31 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id y20so2503977ier.27 for ; Sun, 02 Mar 2014 08:31:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gFgCVJCzmFUe3rdlJ4D5AtcZ480TTGHyI1ZUwqKUoN8=; b=DJXjJ0JWun5ZUcqh9ww2GBdk9cloJBPKhQs4T8JFM7x7Q3m56zc0CArK8bFL33g3lM D54iigualRRe+cgu5DjR5crnw/t3nEKnHFYoXWfSR955gEVn60HHIUGIYmPBdbAIbZ1x mtDtIEaOiajK4HmI2OoLAjBFZoKiqZ7Jc1MQS4BekWEIfc2G2C3e2Cr+EA4L2PXUT/In 7OW5KQRTvGY/Hjrexwo0oYDBJkFCGpNgSMsmY3SOYMFdhYMtyccAfr1kTo/QEHqF+8Q+ nUuCjg1nSMHVKa1GXoGiKB20fhOFaPAE9JuUQDXqp4v6Q+8yvmJO0pqqRRRl7NefByqf OW1g== X-Gm-Message-State: ALoCoQmMhGQZTldX1dCVlhON3Qci0TWOrx8b85NW62aXpJTq1mwkq2NxftqW7ZDUe5cCyzG7qWMG X-Received: by 10.50.43.228 with SMTP id z4mr17116701igl.10.1393777516026; Sun, 02 Mar 2014 08:25:16 -0800 (PST) Received: from netflix-mac.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id mi2sm29951879igb.3.2014.03.02.08.25.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 08:25:15 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: More dangerous UB handling of clang (compared to gcc) From: Warner Losh In-Reply-To: Date: Sun, 2 Mar 2014 09:25:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3DC02993-ADCF-4403-BA0F-61DBEDDB2116@gmail.com> References: <20140228150650.GE29171@hades.panopticon>, <214F7253-A262-4ED1-8E38-672A5ECDFB6D@bsdimp.com> To: Ahmed Charles X-Mailer: Apple Mail (2.1874) Cc: "freebsd-toolchain@FreeBSD.org" 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: Sun, 02 Mar 2014 16:31:32 -0000 On Mar 1, 2014, at 4:18 PM, Ahmed Charles wrote: > ---------------------------------------- >> Subject: Re: More dangerous UB handling of clang (compared to gcc) >> From: bsdimp@gmail.com >> Date: Fri, 28 Feb 2014 08:38:38 -0700 >> To: amdmi3@amdmi3.ru >> CC: freebsd-toolchain@FreeBSD.org >>=20 >>=20 >> On Feb 28, 2014, at 8:06 AM, Dmitry Marakasov = wrote: >>=20 >>> Hi! >>>=20 >>> 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. >>=20 >> Except this is a flat out bug=E2=80=A6. >>=20 >>> Example: >>>=20 >>> --- ub.cc begins here --- >>> #include >>>=20 >>> int func1() { >>> std::cerr << "func1()\n"; >>> /* no return */ >>> } >>>=20 >>> void func2() { >>> std::cerr << "NEVER CALLED\n"; >>> } >>>=20 >>> int main() { >>> func1(); >>> return 0; >>> } >>> --- ub.cc ends here --- >>>=20 >>> --- >>> % 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 >>> --- >>>=20 >>> 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). >>=20 >> This is a flat out bug. When control reaches the end of a function, = it must return, even if there=E2=80=99s no return statement. The value = returned from func1() is, of course, undefined, but this is well defined = behavior in the standard=E2=80=A6 >>=20 >> I=E2=80=99d be very interested to see chapter and verse on this = one... >=20 > n3690: 6.6.3[stmt.return]/p2 >=20 > 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. >=20 > C++ and C are distinctly different in this regard. Seems like the =E2=80=98jump into the next function=E2=80=99 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=3Dreturn-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. >>>=20 >>> Related clang bug: http://llvm.org/bugs/show_bug.cgi?id=3D18296 = (resoleved >>> as INVALID). >>=20 >> I believe this resolution is, in fact, bogus. Sure, insert ud2, but = also put a f=E2=80=99ing return in there. >>=20 >> I know in C11,this id definitely the case: >>=20 >> 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 unde=EF=AC=81ned. >>=20 >> But the C++ standard is somewhat opaque on the topic, but none of the = 56 instances of =E2=80=98undefined results=E2=80=99 in the standard = appeared to apply. >>=20 >>> 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. >>=20 >> Yea, this is a big deal. Sure, people shouldn=E2=80=99t do this, but = this kind of undefined behavior is well outside the bounds of = traditional compilers. >>=20 >> Warner >>=20 >>=20 >> _______________________________________________ >> freebsd-toolchain@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain >> To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org" = =20 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to = "freebsd-toolchain-unsubscribe@freebsd.org"