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

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

[Paul E. McKenney]

Hello!

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?

							Thanx, Paul

[1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2142r1.pdf

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

[Bill Wendling]

On Fri, Jan 10, 2025 at 7:02 AM Paul E. McKenney <paulmck@kernel.org> wrote:
>
> Hello!
>
> 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. 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.)

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.

Cheers!
-bw

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

[Paul E. McKenney]

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:
> >
> > Hello!
> >
> > 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. 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.)
> 
> 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.

Can't say that I disagree with any of this.  ;-)

Other thoughts?

							Thanx, Paul

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

[Segher Boessenkool]

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

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

[Florian Weimer]

* Bill Wendling:

> On Fri, Jan 10, 2025 at 7:02 AM Paul E. McKenney <paulmck@kernel.org> wrote:
>>
>> Hello!
>>
>> 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. 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.)

User-defined pointer-like types obviously have to use -> for the
deference operation because . is reserved for operations on the pointer
object itself.  So certain templated code would have to remember to use
-> anyway.  So it's surprising this proposed in the C++ context.

For C as of today, this wouldn't matter.  However, if we ever get
bounds-carrying pointers, writing p.length or p.limit to access such
information with the pointer p would make sense.

Thanks,
Florian

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

[Bill Wendling]

On Sun, Jan 12, 2025 at 11:57 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Bill Wendling:
>
> > On Fri, Jan 10, 2025 at 7:02 AM Paul E. McKenney <paulmck@kernel.org> wrote:
> >>
> >> Hello!
> >>
> >> 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. 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.)
>
> User-defined pointer-like types obviously have to use -> for the
> deference operation because . is reserved for operations on the pointer
> object itself.  So certain templated code would have to remember to use
> -> anyway.  So it's surprising this proposed in the C++ context.
>
> For C as of today, this wouldn't matter.  However, if we ever get
> bounds-carrying pointers, writing p.length or p.limit to access such
> information with the pointer p would make sense.
>
There's a proposal by Apple to add "fat pointers" to the Clang
compiler [1] (they're using it internally for darwin). From my
understanding, the details of the pointer's internals are hidden from
the programmer, so only the compiler needs to worry about them. (This
is only one method for using bounds-carrying pointers of course.)

[1] https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-in-c-fbounds-safety/70854#internal-bounds-annotations-8

> Thanks,
> Florian
>

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

[David Malcolm]

On Fri, 2025-01-10 at 07:02 -0800, Paul E. McKenney wrote:
> Hello!
> 
> 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?

Is the proposal likely to actually happen to either C++ or C?

I hope the proposal can be ignored; FWIW (with as a GCC diagnostics
maintainer) the proposal seems a bad idea to me: the proposal (in "C++
Compiler modification notes") seems to be suggesting this is a
relatively simple change to the compiler - but it seems to not account
for:

- the cost of teaching language users about the change

- the cost of bifurcating the languages into before/after the change

- providing useful compiler diagnostics if someone tries to compile
code using this with an older version of the language

- support for this in IDEs (e.g. code-completion)

- dealing with smart pointers and operator overloading in C++

- in C++ this may open up a huge can of worms relating to template
substitutions, since it (perhaps; not sure) might allow previously-
failing substitutions to succeed, thus breaking existing codebases

...etc

I don't buy the supposed motivations at all, e.g. "Simplifies the
knowledge required to start programming in C" ...by adding a new
fundamental way to do things, decades in; surely this just complicates
things?

C has its warts, but 

These are just my personal opinions, of course.

Hope this is constructive
Dave

> 
> 							Thanx, Paul
> 
> [1]
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2142r1.pdf
> 

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

[Paul E. McKenney]

On Sat, Jan 11, 2025 at 12:12:45PM -0500, David Malcolm wrote:
> On Fri, 2025-01-10 at 07:02 -0800, Paul E. McKenney wrote:
> > Hello!
> > 
> > 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?
> 
> Is the proposal likely to actually happen to either C++ or C?
> 
> I hope the proposal can be ignored; FWIW (with as a GCC diagnostics
> maintainer) the proposal seems a bad idea to me: the proposal (in "C++
> Compiler modification notes") seems to be suggesting this is a
> relatively simple change to the compiler - but it seems to not account
> for:
> 
> - the cost of teaching language users about the change
> 
> - the cost of bifurcating the languages into before/after the change
> 
> - providing useful compiler diagnostics if someone tries to compile
> code using this with an older version of the language
> 
> - support for this in IDEs (e.g. code-completion)
> 
> - dealing with smart pointers and operator overloading in C++
> 
> - in C++ this may open up a huge can of worms relating to template
> substitutions, since it (perhaps; not sure) might allow previously-
> failing substitutions to succeed, thus breaking existing codebases
> 
> ...etc
> 
> I don't buy the supposed motivations at all, e.g. "Simplifies the
> knowledge required to start programming in C" ...by adding a new
> fundamental way to do things, decades in; surely this just complicates
> things?
> 
> C has its warts, but 
> 
> These are just my personal opinions, of course.
> 
> Hope this is constructive
> Dave

Thank you all!  There is a definite trend thus far.  ;-)

							Thanx, Paul

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

[Jason Merrill]

On Sat, Jan 11, 2025 at 12:13 PM David Malcolm <dmalcolm@redhat.com> wrote:
> On Fri, 2025-01-10 at 07:02 -0800, Paul E. McKenney wrote:
> > Hello!
> >
> > 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?
>
> Is the proposal likely to actually happen to either C++ or C?

Seems unlikely to me.  I don't think it's worthwhile in general to
look at papers targeting the "incubator" study groups, which serve as
a first pass to weed out less interesting proposals and recommend
early improvements for papers that move on to the next step.

Jason

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

[Paul E. McKenney]

On Mon, Jan 13, 2025 at 06:50:21PM -0500, Jason Merrill wrote:
> On Sat, Jan 11, 2025 at 12:13 PM David Malcolm <dmalcolm@redhat.com> wrote:
> > On Fri, 2025-01-10 at 07:02 -0800, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > 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?
> >
> > Is the proposal likely to actually happen to either C++ or C?
> 
> Seems unlikely to me.  I don't think it's worthwhile in general to
> look at papers targeting the "incubator" study groups, which serve as
> a first pass to weed out less interesting proposals and recommend
> early improvements for papers that move on to the next step.

Thank you all!

Given the feedback, I feel comfortable stating that the Linux-kernel
community is opposed to this proposal.

							Thanx, Paul

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

[Peter Zijlstra]

On Fri, Jan 10, 2025 at 07:02:14AM -0800, Paul E. McKenney wrote:
> Hello!
> 
> 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?

After buying a new WTF'o'meter -- reading about this proposal definitely
shattered the old one -- I'm with everybody else so far, this will not
make C better, and if it ever were to pass, we should ensure the kernel
does not use it.

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

[Paul E. McKenney]

On Mon, Jan 13, 2025 at 12:16:24PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 10, 2025 at 07:02:14AM -0800, Paul E. McKenney wrote:
> > Hello!
> > 
> > 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?
> 
> After buying a new WTF'o'meter -- reading about this proposal definitely
> shattered the old one -- I'm with everybody else so far, this will not
> make C better, and if it ever were to pass, we should ensure the kernel
> does not use it.

You should see some of the other proposals!  Or maybe not?  After
all, you should get some use out of your new WTF'o'meter.  ;-)

							Thanx, Paul