In C++, you can overload the comma operator to do shit. I've seen it done. There's no reason to do it, and no reasonable person would ever expect it in a code base they're unfamiliar with. To find bug in that ultimately roots back to that implementation, you have to go eliminate every other whack-job possibility before it even occurs to you that maybe the weirdo who wrote this code chose to overload the comma operator.

I'm not going to argue with anyone who wants to use C++ in their own projects, you do you. But let's be real about what C programmers are complaining about. It's not line count. It's syntactic obfuscation. I don't just level this criticism at C++ either. Basically every major new language has its own byzantine syntactic constructs to some degree.

If there's a trap for the upper-middle class, it's for the W2 earners. The federal tax code essentially disqualifies high-income W2 earners from virtually every deduction. Both parties wind up soaking these taxpayers because they

- make a lot of money,

- don't own a business, and

- don't have an organization like the Chamber of Commerce to lobby on their behalf

When Republicans get into power, these people are likely to vote Democratic and are therefore okay to stick with the bill after cutting taxes for dentists, lawyers, and corporations. When Democrats are in power, these people are (as ever) not "paying their fair share", so they need their taxes hiked to pay for free stuff for people who don't vote for Democrats. And then they'll also be disqualified from taking advantage of those new benefits/entitlements.

I don't think that the choices should be "self-driving cars" and "cars with no seatbelts, airbags, or crumple zones" with nothing in between.

void *__free p = NULL;

func(&p); // func zeroes p to claim ownership

// end of scope, p is NULL, nothing happens // if func was not called, p is freed

I think I had seen noplate before -- looks like you're taking advantage of the anonymous struct compatibility changes in C23? Those are going to open up a lot of possibilities. Regardless I'd love to stay in touch -- by "us" do you mean the working group?

I don't have any clue how to patch clang's front end. I'm not a language or compiler person. I just want to make stuff better. There needs to be a playground for people like me, and hopefully lib0xc can be that playground.

What lib0xc has is some cleanup attributes that you can apply to variables to e.g. automatically free a heap allocation or close a file descriptor, at end of scope. Personally, I like variable annotations much more than defer for these uses, but they accomplish the same thing. I've also found that using those attributes inherently pushes your code to make ownership more explicit. I personally stopped being terrified of double-pointers and started using them for ownership transfers, which eliminates a large class of bugs.

If you get compiler errors, it means you were printing to a heap-allocated buffer (or a buffer whose bounds you did not know), and you should be propagating bounds and using `snprintf`.

Integer conversion is the same way. If you have something like

int v1; uint64_t v2;

v2 = (uint64_t)v1;

Then you can replace it with

v2 = __cast_signed_unsigned(uint64_t, v1);

and you'll get a runtime trap when v1 is a negative value, meaning you can both enable -Wint-conversion and have defined behavior for when the value in a certain integer type is not representable in another.

I really need to learn more about Zig, but from what I know, there are still worlds of possibilities that a modern, well-designed language offers over something like lib0xc. Zig's ability to evaluate any expression at compile-time is one such example.

But generally, lib0xc gives you bounds-safety everywhere it can. Languages like Zig and Rust give you type-safety to their own degrees, which I think is a superset.

> What do you think C would need in order to reach the user experience of those languages?

Not really having direct user experience, it's hard for me to say. But if I what I can give you is a list of features that would make large parts of lib0xc irrelevant:

1. Protocols/traits

2. Allocating from a caller's stack frame (think, returning the result of `alloca` to the caller)

3. printf format specifiers for stdint.h types and for octet strings

4. Ability to express function parameter lists as structures

5. New sprintf family that returns a value which is always less than or equal to the size passed (no negative values)

Basically, I think that the C standard should be working aggressively to cut down on the use cases for heap allocation and `void *`. And I think that the bounds safety annotations should become first-class language features.