Quotes of the week

[Posted January 15, 2025 by corbet]

Currently, given a pointer "p", C allows p->a but not p.a. There is a proposal from C++ that is being considered for C.
Do we care?

— Paul McKenney

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.

— Peter Zijlstra

Mayhem would ensue

Posted Jan 16, 2025 18:58 UTC (Thu) by ncultra (✭ supporter ✭, #121511) [Link] (1 responses)

A great argument for adding -std<=c23 to all makefiles and enabling that switch or its equivalent by default in all future C compilers.

Mayhem would ensue

Posted Jan 16, 2025 19:06 UTC (Thu) by adobriyan (subscriber, #30858) [Link]

After many years C finally accepts "void f(int){}" so there is infinitesimal amount of hope and prayers for the language.

C++ seems like the language that shouldn't have this.

Posted Feb 3, 2025 21:01 UTC (Mon) by Spudd86 (guest, #51683) [Link] (1 responses)

Honestly to me this seems far more sane in C than C++, C being a simpler language I can't think of cases where I care about the difference between p.a and p->a when writing a function past using the right one. Which just annoys me when I refactor from quick and dirty code with a struct on the stack in main to splitting it into functions that take a pointer.

C++ on the other hand because it lets you overload things so that you might have an object where you could use both operators on it and do different things allowing one in place of the other seems insane.

C++ seems like the language that shouldn't have this.

Posted Feb 3, 2025 22:28 UTC (Mon) by excors (subscriber, #95769) [Link]

I see one significant reason to care about the difference in C: it tells you whether you need to worry about null pointers. You can trivially tell that code accessing `s.x.y` is safe, but if the code is accessing `s.x->y` then you'll need to verify `s.x != NULL` (either with a test in the code, or a documented guarantee).

In the other languages mentioned in the proposal, a null dereference will give you an exception, which is just a bug. In C/C++ it's a security vulnerability, so it's pretty important to be aware of your pointer dereferencing.

Also it's a bad idea in C++ because smart pointers use `->` to access members of the pointed-at object and `.` to access members of the smart pointer itself. The proposal only changes the syntax for dereferencing raw pointers, so they would no longer match smart pointers, increasing confusion; and modern C++ should almost always be using smart pointers or references instead of raw pointers, to make ownership and lifetimes clearer, so even the proposal's hypothetical benefits wouldn't apply.

Anyway, judging by https://github.com/cplusplus/papers/issues/868 there's zero support for the idea so there's no need to worry about it.