From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 4757E24B231 for ; Sat, 11 Jan 2025 08:20:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=63.228.1.57 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736583636; cv=none; b=MmIxiIOjC+bfhrFokTHsdF4mWk+tzxRkSU3a+QTbQ73FqqXsEJqlwD7pSG9JQggectNZj585DW9LVsj2rq72670YpmnuEGbCOFduuQKN8lxeqfwH5pyQYQclMAF9DarkXAEO2Zw4bp4e6btt7iYuyjxiIsRWX9Muvda2THRHQDI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736583636; c=relaxed/simple; bh=UTRWV1S/JOZJzXCGuvawi2SNxsUJv8nL0SjHanYzHJQ=; h=Date:From:To:Cc:Subject:Message-ID:References:Mime-Version: Content-Type:Content-Disposition:In-Reply-To; b=bDCPhr4EORreHdOuIJwp+ztJAPs0Zr4vHgbLtLQf5438OfC4/5A9n7VHDLEAiIiuRAhJ2kqbOYK02VdQLof3NWV+3nwHEdpvxZNCtRqBYLC2/FSz6NrFm3wGfzIkq1kv5HljGIdzC06DlkwQRWTV85WVl0C6cPz1jKqEqW7Szk8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org; spf=pass smtp.mailfrom=kernel.crashing.org; arc=none smtp.client-ip=63.228.1.57 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 50B7tuH3019076; Sat, 11 Jan 2025 01:55:56 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 50B7tuKp019073; Sat, 11 Jan 2025 01:55:56 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Sat, 11 Jan 2025 01:55:55 -0600 From: Segher Boessenkool To: Bill Wendling Cc: paulmck@kernel.org, linux-toolchains@vger.kernel.org Subject: Re: Do we care if C compilers start allowing "." on pointers? Message-ID: <20250111075555.GS20626@gate.crashing.org> References: <6c55adc5-52f9-45e2-aa20-ef344c9dd1ea@paulmck-laptop> Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Hi! On Fri, Jan 10, 2025 at 05:09:21PM -0800, Bill Wendling wrote: > On Fri, Jan 10, 2025 at 7:02 AM Paul E. McKenney wrote: > > Currently, given a pointer "p", C allows p->a but not p.a. There is a > > proposal from C++ [1] that is being considered for C. > > > > Do we care? > > > Does the proposal seem likely to be added to C++? The motivation is > very weak, in my opinion. Yes. Especially this part: """Other languages (JS,Rust,Ruby,Python,Go,C#,Java,Kotlin,Swift,ObjC), indirectly derived from C have come to just use '.' as an operator;""" The only way that those languages can be said to be indirectly derived from C is that they have similar syntax. With quite different semantics in most cases, of course. > Other languages are very different from > C/C++; they try to hide away memory management details, which are a > major part of C languages. (To prevent a holy war, my comments aren't > about the benefits and drawbacks of memory management in other > languages.) The distinction between . and -> helps the user avoid many common stupid mistakes. This proposal makes life harder for the user. If that is the actual goal here, good proposal then, but otherwise, not so much. > As for the kernel, if C/C++ adopt this convention, we won't be able to > accept contributions which use '.' to access pointers until the > minimum version of the compilers support this feature, which I imagine > will take several years. My personal opinion would be to require '->' > even when the option is available, unless a much better motivation is > made. With "several" being at least seven. Yes. And it would make sense to stay close to the old coding style stuff anyway, it has proven its value. Btw. I can guarantee there will be a warning for ". used on a pointer". Read that as a prommise if you want :-) And although I always say that -Werror is one of the worst ideas of the last decade, I would support doing -Werror=pointer-dot for all of the kernel. It's not so bad there: actually upgrading a warning to an error is a user choice (while doing this only so that others cannot as easily ignore the warnings, i.e. the usual case, is the worst kind of bureaucracy). Segher