From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A5A7082D98 for ; Tue, 23 Jan 2024 20:20:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706041236; cv=none; b=oDFYMb2vJ9cqE0tSa6fBbZmVOOO1fouRKTsCJXCu3V2OgX5wLl/8KMfuCXgAxJXKsBockA2XDKkNCTN3hO48KAnvfE4WOfG4via16ywHKh6mqzrcCO3MzRJ/MZxsGiopZcUJYe0rxpci6qw2DL+MHY/qK1I/hmH0R/fMMpRR6bQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706041236; c=relaxed/simple; bh=64iti4G3H2nntXXx1kjdeL6PYt4jdB0gTF1hLHoEUXQ=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=UpCCRGcklZ5kxOkfP6KZVaSBr8B8HE2K9bUH6E6BIbq27IIRcAwt21sZgFVpep+qdB9lJvxcNdpl9nEWJEkvdM9oFFz9ttdTDfDjuh3PSDSjF15jTjxrvYwzagoc/Dys8ixp2S9OfQCcqdMYi8A11ng78vgbS/RfUV3rSMw2ebQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org; spf=pass smtp.mailfrom=linuxfoundation.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=DDA4NrZ8; arc=none smtp.client-ip=209.85.208.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linuxfoundation.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="DDA4NrZ8" Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-55c2cf644f3so2819690a12.1 for ; Tue, 23 Jan 2024 12:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1706041232; x=1706646032; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uZo11nKt8Xio3vk+DD3aCDd8x3FzMqp66Qn5QTfiImk=; b=DDA4NrZ8n0fzGgtIaDN4Xu5NLd1gz13sRGvLqZk94ULD6YYjhzZY7KdjaYKvuckgA4 QYe3HRLwK5soKWODfmd9rQGZ5yf7+SxQKV9DfgXEGtDA0zD5ec5nYlJtlVsCBfwMPYA8 Lfg4sYIbbLr9v/OWqp+8tX7oVsfxv4n2TeB4k= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706041232; x=1706646032; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uZo11nKt8Xio3vk+DD3aCDd8x3FzMqp66Qn5QTfiImk=; b=ZnvZ0+Y01BdfiUKvn0LsVjrUJ1s6f9B90VhWQ/j3P9DbNe5DDHEjvp3hew3GnRXqVW gbMDSrqzUbjyNKLVWprroPKP+RqhhmaPnau5AZqQ3K5PSiordhyjMenZql9oHVEDkBZW jj+wRmKzGlZwQS9CMsOSQxH7XvvJOpAXI3DHYFjOEBbTG67V4h6MG57tudMsIS/wbvvo lSI/zLJst0Lcs2Hk0ceyAowD011a+8nZKBIr0QhUICi533vE/KY9pKWamkAt0a88TKtC T7ACSLvTxNk+wj88xB6QCivKCXv+rVhMaAoogBxNBMn/lFTVMce27Z6W32hnwgAxbJ+Y W3xw== X-Gm-Message-State: AOJu0Yw01Uj4HjRZt18LruWe2ZZrL87+ZwcyIZ2LBcIf0Nter/fcGN1M 5Ef/rASaDSA9RuS6wk6PdGtWzCQeUvHHmP8VnQbFnHA6FJpcQb1JzZF83yUGMasfe7egMBgdfNu IlRPJkw== X-Google-Smtp-Source: AGHT+IE9rvR4PlIJLOkn0IgQyZWTuN2b9kL/tTVh1TtsB9qsfSDgyIZgRmPrq/az66g+GBdJUKgaEg== X-Received: by 2002:a05:6402:18:b0:55a:4e1b:7238 with SMTP id d24-20020a056402001800b0055a4e1b7238mr1114787edu.2.1706041232591; Tue, 23 Jan 2024 12:20:32 -0800 (PST) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com. [209.85.208.46]) by smtp.gmail.com with ESMTPSA id k17-20020aa7c051000000b005574ffc25a0sm15739912edo.31.2024.01.23.12.20.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 23 Jan 2024 12:20:31 -0800 (PST) Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-557dcb0f870so5645599a12.2 for ; Tue, 23 Jan 2024 12:20:31 -0800 (PST) X-Received: by 2002:a05:6402:6c6:b0:55c:537f:d3e6 with SMTP id n6-20020a05640206c600b0055c537fd3e6mr1159605edy.40.1706041231179; Tue, 23 Jan 2024 12:20:31 -0800 (PST) Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <9162660e-2d6b-47a3-bfa2-77bfc55c817b@paulmck-laptop> <70fd47bb-1539-4301-9cd0-1b94aa066205@paulmck-laptop> In-Reply-To: <70fd47bb-1539-4301-9cd0-1b94aa066205@paulmck-laptop> From: Linus Torvalds Date: Tue, 23 Jan 2024 12:20:14 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: A few proposals from the C standards committee To: paulmck@kernel.org Cc: linux-toolchains@vger.kernel.org, peterz@infradead.org, hpa@zytor.com, rostedt@goodmis.org, gregkh@linuxfoundation.org, keescook@chromium.org Content-Type: text/plain; charset="UTF-8" On Tue, 23 Jan 2024 at 12:00, Paul E. McKenney wrote: > > Would you be OK with something that required a new variable for the > pointer that was now known not to be NULL? (My guess is "no", given the > following discussion on value ranges, but I figured that I should ask.) Yeah, no, I think that ends up putting the burden on the programmer in the form of a very cumbersome syntax, and just more room for mistakes. > In some implementations, you can use assertions to get at least part > of this effect: 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. Linus