From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id B84CE1382C5 for ; Thu, 10 May 2018 13:35:50 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8EB29E0B4B; Thu, 10 May 2018 13:35:42 +0000 (UTC) Received: from smtp.hosts.co.uk (smtp.hosts.co.uk [85.233.160.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1F56FE0AE8 for ; Thu, 10 May 2018 13:35:41 +0000 (UTC) Received: from [86.152.238.84] (helo=[192.168.1.137]) by smtp.hosts.co.uk with esmtpa (Exim) (envelope-from ) id 1fGljP-0003iN-CX for gentoo-user@lists.gentoo.org; Thu, 10 May 2018 14:35:40 +0100 Subject: Re: [gentoo-user] Re: Spectre-NG To: gentoo-user@lists.gentoo.org References: <1549166.RPGoRN5ZiQ@dell_xps> <5AF34625.9010708@youngman.org.uk> <20180509225012.tbzlrx2b623tkc7f@matica.foolinux.mooo.com> From: Wol's lists Message-ID: Date: Thu, 10 May 2018 14:35:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20180509225012.tbzlrx2b623tkc7f@matica.foolinux.mooo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Archives-Salt: cb5b0467-6e4a-4567-97d0-c708bde83581 X-Archives-Hash: 993a61555f8766dd2e86cf743ccdc012 On 09/05/18 23:50, Ian Zimmerman wrote: > Code may be "security-sensitive" but buggy. Is the compiler writer > really responsible for guessing what the programmer meant to accomplish > with buggy code? What do you mean by "buggy"? > It would of course be preferable if the compiler could > just abort with an error when it detects UB, but that turns out to be > very hard to impossible in the case of C. That's just a built in > problem with the language. So if the compiler can't detect undefined behaviour, how the hell do you expect the programmer to? Oh - and please explain - what is buggy about wanting the following program to compile and actually *do* what the code is asking, rather than compiling to a no-op ... int main () {   int a, b, c;   a = 2;   b = 4;   c = 6; } Note I did say the problem is almost invariably when hardware gets involved - what happens if it's int main () {   void *a;   a = 0x00ff;   *a = 6; } and 0x00ff is the address of your network adaptor? Do you want THAT to be optimised away "because it doesn't do anything"? That's why I expect LVM/Clang is much better - because I believe Intel is heavily involved they provide guarantees about how the compiler will interact with hardware, when the C standard explicitly avoids specifying it (imho, the standard should require a compiler to document how it handles things like that ...). (Yes I believe there is some compiler option to make that work, but I'm pretty certain that either is or was undefined behaviour to start with? And if it is now standard, it's probably because some clever idiot optimised the "code which doesn't do anything" away and they had to define a way of stopping it?) Cheers, Wol