From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F7B94A3B for ; Tue, 23 Jan 2024 20:47:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706042844; cv=none; b=ePG2B6j1ugWxWpEhoDO9d7bIteDrx2hOBHcg1LYzJB0ulJIlytQwTywimkWzvdPqk05sH64ejW+0X7fnxl8PSvlFXFsQodXJPsGGDeDeWkOEYDJsU7hw8AauBxZtt9RXm0E+jUvfKB7fo2VdapbFgCdzbFSg0G6iassOzsPGrYU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706042844; c=relaxed/simple; bh=BdVieXhlVgPnuSJmwDOtsfuJDlfXmbGkWEiVbit+mA8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ciJAqqah9VqXVXahCzmW/hePKTbeE3YtC544unFVUE1T+Rfh/nJR44g3FNzHyBVavXWsgym9SYVkg5D/G5geI3yPMhd847ubpgYgr/o+5Yqyrixk+0dcGhedSv6434thXHwplXfm7rRFniLYjM1gGG+/cws3PFGpY8zKybFOdYk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=Sn9nbr0o; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="Sn9nbr0o" Received: from [IPV6:2601:646:8002:4640:7285:c2ff:fefb:fd4] ([IPv6:2601:646:8002:4640:7285:c2ff:fefb:fd4]) (authenticated bits=0) by mail.zytor.com (8.17.2/8.17.1) with ESMTPSA id 40NKisK03270814 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 23 Jan 2024 12:44:55 -0800 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 40NKisK03270814 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2024011201; t=1706042695; bh=iHdZkks025lltNOU0lgH3fh7IQZpyyvZ53jLreXVg9w=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Sn9nbr0oFOeZ0pBzREapkPmFDJOYAI+v2IY8OzPMZos4jlgs3qiSEXquALrcgD+Xl jtOGmzZGZ6ep+TN2/imDpcP0kEnrUWbhKQek9LfE5H7ddBFLRDN9/dXGXHCVwpfGLX ks2l7msnX+JopEdzsrKtY/Noe247zofW34ucEa8AXyTr0IadQ1A7E58cXTNQgdXpa6 ZGnztBsUgNKkm3htJOcclWMIuxCWZ232+2Q/6DPunfomZbSjuWFNXIK0xSfg/tlB8K f3VRBRtKuZDnVbCYXtQb7n3Q53bv0dflmkLaHdrDzwmpPqt6xPU28mx7axAT8VfYio 0dCz6jzaqud/w== Message-ID: Date: Tue, 23 Jan 2024 12:44:49 -0800 Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: A few proposals from the C standards committee Content-Language: en-US To: Linus Torvalds , paulmck@kernel.org Cc: linux-toolchains@vger.kernel.org, peterz@infradead.org, rostedt@goodmis.org, gregkh@linuxfoundation.org, keescook@chromium.org References: <9162660e-2d6b-47a3-bfa2-77bfc55c817b@paulmck-laptop> <70fd47bb-1539-4301-9cd0-1b94aa066205@paulmck-laptop> From: "H. Peter Anvin" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/23/24 12:20, Linus Torvalds wrote: > > Yes. However, the problem with that is that the assert generally then > comes with extra code generation. > > IOW, a plain > > _Nonnull p; > > in my opinion should imply a promise by the developer - and then you > could have some "debug build" model where the compiler then verifies > the promises. > > But an > > assert(p); > > implies more than a promise by the developer - it implies that the > compiler *should* generate some code to verify. > > And yes, obviously assert() comes with the traditional NDEBUG flag, > but that one has the historical baggage of causing the assert() to be > a no-op. IOW, you lose the code generation, but you also lose the > promise from the developer. > > Could all of this be done *properly*? Yes. And I think it should. But > properly literally means having good documented "this is what this > means". > > And no, __builtin_unreachable() is not it either, because it again has > the same issue as "assert()" - in *practice* compilers can use it as a > hint, but that's an incidental result, not part of a documented "this > is how you specify a known range" > > So yes, I can do things like > > if (a < 0) __builtin_unreachable(); > > and it will generate the *code* that I want, but it sure as hell isn't > some standard C syntax. > C++23 adds [[assume(x)]]; which presumably will be "backported" to the C standard. This is basically MSVC's __assume() or gcc's __attribute__((assume())) which is otherwise exactly equivalent to using an if statement or && to invoke unreachable(); the latter has the advantage that if you use a macro you can replace unreachable() with something else for debugging purposes. unreachable() is in C23, in , so if (a < 0) unreachable(); or ((a < 0) && unreachable()) actually *is* standard C syntax now... -hpa