From owner-freebsd-toolchain@FreeBSD.ORG Fri Feb 28 15:38:43 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 83A8C4A8 for ; Fri, 28 Feb 2014 15:38:43 +0000 (UTC) Received: from mail-pb0-x231.google.com (mail-pb0-x231.google.com [IPv6:2607:f8b0:400e:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 576011836 for ; Fri, 28 Feb 2014 15:38:43 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id jt11so898539pbb.36 for ; Fri, 28 Feb 2014 07:38:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KmuKkCGqZ0Lq/IFb8NW4x2ms0WyNzZnl/BcAld+W1oY=; b=kcKUFbHgS9cwmjnmtm48RDE9lxNKb0MvJZnQW5PSHFfXLvEdBn2TOCxNE0KezBmvXG FliJNkFkcsJgTL4X5kBCzQ65z+AXNCBA3FVHGrDFjPlmo3+Zs8fg4vnhGHrZVOF3TkMM y83JqaWg73sgteyCJPf+UgGl8YBsDs6mvAyzTufGzm3svXWes1onOUcX/CHT9z/R2EDO RZJweB06jYESA2E+SxXRR+uRM1G0gLkQ2iUitMSXraPWQG+H2SJYChxgPMjZdtghVvKQ Orl5tSV/FnOH3BT2QAfO4VfAdO/P+NDefE0yZuT+5Dqz2BVTYjQfKXmNJ0N86jwkcU5p VeWQ== X-Received: by 10.68.212.161 with SMTP id nl1mr4242280pbc.142.1393601922940; Fri, 28 Feb 2014 07:38:42 -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 ou9sm7281094pbc.30.2014.02.28.07.38.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Feb 2014 07:38:41 -0800 (PST) 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: <20140228150650.GE29171@hades.panopticon> Date: Fri, 28 Feb 2014 08:38:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <214F7253-A262-4ED1-8E38-672A5ECDFB6D@bsdimp.com> References: <20140228150650.GE29171@hades.panopticon> To: Dmitry Marakasov 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: Fri, 28 Feb 2014 15:38:43 -0000 On Feb 28, 2014, at 8:06 AM, Dmitry Marakasov wrote: > 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. Except this is a flat out bug=E2=80=A6. > 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). 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 I=E2=80=99d be very interested to see chapter and verse on this one... > 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). I believe this resolution is, in fact, bogus. Sure, insert ud2, but also = put a f=E2=80=99ing 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 unde=EF=AC=81ned. 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. > 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=E2=80=99t do this, but = this kind of undefined behavior is well outside the bounds of = traditional compilers. Warner