Re: Do we care if C compilers start allowing "." on pointers?

[Segher Boessenkool <segher@kernel.crashing.org>]

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 <paulmck@kernel.org> 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