From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) (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 1FFC11891A9; Wed, 26 Feb 2025 13:03:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740575018; cv=none; b=XamUFe2Nlmzftthls4NrY5ny35wVchiwpRy25Wyg9ehpNC0HND+54tZIbcN0yhenw4zWn64UA+zNKhxHTYHflZkhiaAlQYBHmcC396ao8jWFmo4ay00dkQydR9iX11pdd6E35JYWt4wsysaJqVNcAybVMGUthtUnqgsOUA2YW8Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1740575018; c=relaxed/simple; bh=eHXH2xcwHvpeP2rTbNNDIAknPYHbqmdnpV8ggdyjZ7M=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Svoh9Q7oiPGw3De4tPzQ02Z7xsBUrNa1hzfpCPu91mWRMMx5KQRee3r9+EpFlqhA/no48NzNWW5OUputxjTEu7kOo1BynouCW/2azXm2PgAZv/a8xO5K1dCRa/TJ1dQKjMLI68GBnhau6SEY4IPzP8aN8GJ6COy+sIGFUtEdCG8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=E8/7CjMn; arc=none smtp.client-ip=209.85.167.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="E8/7CjMn" Received: by mail-lf1-f45.google.com with SMTP id 2adb3069b0e04-5461dab4bfdso8013600e87.3; Wed, 26 Feb 2025 05:03:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740575015; x=1741179815; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OOaAyIgCFX8Depn/PozouTZSxlQDaDtgCKWZ+jCIr88=; b=E8/7CjMn1kbAPnjhKJeOSvnDX2ffIHZEor8AXIe9+2OFoPwTvqeyLAHCy9eB719KAZ mC0Hokq/E5lZOUb73xpW/lr+MMPuKoFlpo0Vv2LTldb7dsK1uEFOOylrFOL22przRUsx SCy+01cRq6Zzbv/YBChx9L1oWH7nGO0azfcct55QgPvCEsNTZtKQldrAJsSjixow5dp4 DG3i8yrWEIB/DC+Wnbu2XSZUX+gROSFMXFgbWiHXVC7j35MJOklx+LKkto1Yibef0Jue zhaT5Zjr0hmC/3GmeJgWZLStNWwUTR7VmtsrzjsX8BDIDwElW+T66HBp9Y8D+Te53pIG +oJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740575015; x=1741179815; h=content-transfer-encoding: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=OOaAyIgCFX8Depn/PozouTZSxlQDaDtgCKWZ+jCIr88=; b=uYMbfZkvLKuCV6LoI/nNhMUjngp9StNET5D9HS9MG07cR78K/ZipnLQMMewu9mUvUG x+UDGwwlQk6rm/yh3U0gZyC8zwPEsf43jhTNy0R5zIPHNufvpBv25/eNNGaLhQfkAPPs OpSPSYbquUD8kbbe+XLuQ3jAa1bROLLgxNPyxF5NoczwhiwgFqNvyAL8a/CcxIYvUjIX lCmcONYpzCD2Z9ri1mRYjfg0YzdnusAKxhsq1DNyQnnH3O/fSaaAO0rdM7Aly0YVRns2 mapeV172WeOqfXP6VkhE08YQuWDtpQNE4BKW/t0o3LaTpwgNLYVkkdAjWyS5MSrE32Qo IdmA== X-Forwarded-Encrypted: i=1; AJvYcCWdd28eGA7olQXiOscqVm2SODPlUG1mMKtWGkPawFIsQ3r0jbp9d7dX7ROt0aikfFHt6uvn3Ni/Ad/bxmI=@vger.kernel.org, AJvYcCXGv35DwHEQmvtUrvdmUNYQf2lNEijIZ/6d8sxkDrKOCbEyeOToZISV648yi/pbkjsxyiqu5kMchFiD/+KY1us=@vger.kernel.org X-Gm-Message-State: AOJu0YzDWCnDF6OnwshAiIYP3edbyNOtvRBAhRM2F9+1GGymm/zRpOfY s6qFGklOf53dxWE133vtd5f9hCOK/AEjB8Z1YePy7nL/N/+4Y04f92JoVSg3XGQvFygUv6fCdNM j/LZsyu4+O/EFqJa/vq1KfMaRbWg= X-Gm-Gg: ASbGncvekjZBzJJp2ydtCTPhasNF0fVqEp1pRpjJuF26XfBibVZt01RpRm2TWdqBgPr kmejou3GfOriJd4jA4pcFNDeN+0ZNeiFCTiA1b1nORLwFqvhgcLE32gAjI9Gv5NzpQbnYQYY2R3 k3kNZ/hl2y X-Google-Smtp-Source: AGHT+IF4/7i4cn3DiJ773zF8xOQe9L3YSlR5TCr/4/VVZsgTQa7dvgs28vk0rkrTCUmUnVPKqxiqJEINXiihbPUT3OY= X-Received: by 2002:a05:6512:e99:b0:545:6fa:bf5f with SMTP id 2adb3069b0e04-54838edd8b6mr9406658e87.2.1740575014818; Wed, 26 Feb 2025 05:03:34 -0800 (PST) Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250222141521.1fe24871@eugeo> <6pwjvkejyw2wjxobu6ffeyolkk2fppuuvyrzqpigchqzhclnhm@v5zhfpmirk2c> <5E3FEDC4-DBE3-45C7-A331-DAADD3E7EB42@zytor.com> <2rrp3fmznibxyg3ocvsfasfnpwfp2skhf4x7ihrnvm72lemykf@lwp2jkdbwqgm> In-Reply-To: <2rrp3fmznibxyg3ocvsfasfnpwfp2skhf4x7ihrnvm72lemykf@lwp2jkdbwqgm> From: Ventura Jack Date: Wed, 26 Feb 2025 06:03:20 -0700 X-Gm-Features: AQ5f1JoDaaLCqIcdIZhNNBP4aubytjJzFmRPFjw-ljPopqVIQo-B9DJXO1CskAM Message-ID: Subject: Re: C aggregate passing (Rust kernel policy) To: Kent Overstreet Cc: "H. Peter Anvin" , Alice Ryhl , Linus Torvalds , Gary Guo , airlied@gmail.com, boqun.feng@gmail.com, david.laight.linux@gmail.com, ej@inai.de, gregkh@linuxfoundation.org, hch@infradead.org, ksummit@lists.linux.dev, linux-kernel@vger.kernel.org, miguel.ojeda.sandonis@gmail.com, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 25, 2025 at 1:21=E2=80=AFPM Kent Overstreet wrote: > > On Tue, Feb 25, 2025 at 10:16:17AM -0800, H. Peter Anvin wrote: > > > > I do have to say one thing about the standards process: it forces a > > real specification to be written, as in a proper interface contract, > > including the corner cases (which of course may be "undefined", but > > the idea is that even what is out of scope is clear.) > > Did it, though? > > The C standard didn't really define undefined behaviour in a > particularly useful way, and the compiler folks have always used it as a > shield to hide behind - "look! the standard says we can!", even though > that standard hasn't meaninfully changed it decades. It ossified things. > > Whereas the Rust process seems to me to be more defined by actual > conversations with users and a focus on practicality and steady > improvement towards meaningful goals - i.e. concrete specifications. > There's been a lot of work towards those. > > You don't need a standards body to have specifications. Some have claimed that a full specification for aliasing missing makes unsafe Rust harder than it otherwise would be. Though there is work on specifications as far as I understand it. One worry I do have, is that the aliasing rules being officially tied to LLVM instead of having its own separate specification, may make it harder for other compilers like gccrs to implement the same behavior for programs as rustc. https://doc.rust-lang.org/stable/reference/behavior-considered-undefine= d.html http://llvm.org/docs/LangRef.html#pointer-aliasing-rules Interestingly, some other features of Rust are defined through C++ or implemented similar to C++. https://doc.rust-lang.org/nomicon/atomics.html "Rust pretty blatantly just inherits the memory model for atomics from C++20. This is not due to this model being particularly excellent or easy to understand." https://rust-lang.github.io/rfcs/1236-stabilize-catch-panic.html "Panics in Rust are currently implemented essentially as a C++ exception under the hood. As a result, exception safety is something that needs to be handled in Rust code today." Exception/unwind safety may be another subject that increases the difficulty of writing unsafe Rust. At least the major or aspiring Rust compilers, rustc and gccrs, are all sharing code or infrastructure with C++ compilers, so C++ reuse in the Rust language should not hinder making new major compilers for Rust. Best, VJ.