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

On Sun, Jan 12, 2025 at 11:57 AM Florian Weimer <[email protected]> wrote:
>
> * Bill Wendling:
>
> > On Fri, Jan 10, 2025 at 7:02 AM Paul E. McKenney <[email protected]> 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
>