Comment by SkiFire13 | Hacker News Reader

Comment by SkiFire13 | Hacker News Reader

Parent Full thread

> C3 not having to implement any recently popular language features in order to solve the problem of memory lifetimes for temporary objects as they arise in a language with C-like semantics.

But you said it yourself in your previous message:

> A dangling pointer will generally still possible to dereference (this is an implementation detail, that might get improved – temp allocators aren't using virtual memory on supporting platforms yet)

So the issue is clearly not solved.

And to be complete about the answer:

> in safe more that data will be scratched out with a value, I believe we use 0xAA by default. So as soon as this data is used out of scope you'll find out.

I can see multiple issues with this:

- it's only in safe mode

- it's safe only as long as the memory is never used again for a different purpose, which seems to imply that either this is not safe (if it's written again) or that it leaks massive amounts of memory (if it's never written to again)

> Now clearly people are misreading the title when it stands on its own as "borrow checkers suck, C3 has a way of handling memory safety that is much better". That is very unfortunate, but chance to fix that title already passed.

Am I still misreading the title if I read it as "C3 solves the same issues that the borrow checker solves"? To me that way of reading seems reasonable, but the title still looks plainly wrong.

Heck, even citing the borrow checker *at all* seems wrong, this is more about RAII than lifetimes (and RAII in Rust is solved with ownership, not the borrow checker).

> So the issue is clearly not solved.

You can use --sanitize=address to get this today, or use the Vmem-based temp allocator (which is only in the 0.7.4 prerelease and only for 64 bit POSIX) if you're curious how it feels and works in practice.

> I can see multiple issues with this:

There is a constant trade-off, and being as safe as possible is obviously great, but there is also the question of performance.

The context matters though, it's a C-like language, an evolution of C. So it doesn't try to be a completely new language with new semantics, and that creates a lot of constraints.

The "safe-C" C-dialects usually add a lot of additional annotations that doesn't seem particularly palatable to most developers.

> Am I still misreading the title if I read it as "C3 solves the same issues that the borrow checker solves"?

Yes I am afraid you do. But that's my fault (since I suggested the title, even though I didn't write the article), and not yours.

> You can use --sanitize=address to get this today

By the same argument you could say that C/C++ also solved memory safety then. Do you compile production code with `--sanitize=address`? Note that certain sanitizers can be unsafe to use in production due to e.g. reading some environment variables.

> or use the Vmem-based temp allocator (which is only in the 0.7.4 prerelease and only for 64 bit POSIX)

FYI it would be useful to pair claims of features with documentation that describes how they work, otherwise we may be just talking past each other. Seeing "vmem" mentioned this seems like it is just going to leak virtual memory address space.

> There is a constant trade-off, and being as safe as possible is obviously great, but there is also the question of performance.

You're changing argument. You can claim that C3 does not aim to solve memory safety for these reasons, _and they can be understandable_, but then don't go and claim you solved memory safety anyway because that's plain false.

> Yes I am afraid you do. But that's my fault (since I suggested the title, even though I didn't write the article), and not yours.

Some more argumentation would be nice. How am I misreading the title? If I'm misreading it then there should be another way of reading it that's more obvious and make sense. I have yet to see a reasonable way of reading it where the mention of the borrow checker makes sense.

> You can claim that C3 does not aim to solve memory safety for these reasons, _and they can be understandable_,

This seems to be where we speak past each other. What the blog post talks is how C3 handles the problem of memory lifetimes for temporary data, which is a major lack of ergonomics in C (and arguably also C-likes, such as Zig).

The title refers to how C3 does this is in userland without having to add any of the common solutions, such GC, ARC, RAII. Recently a superset of C called "Cake" added ownership annotations exactly to solve such problems.

C3 doesn't have anything like Rust memory safety. Nor is the blog post about memory safety, but on memory lifetimes.

> The title refers to how C3 does this is in userland without having to add any of the common solutions, such GC, ARC, RAII.

No, the title does not mention any of those. Instead it mentions "borrow checking" and that solves a completely different problem that C3 does not even attempt to tackle.

Reply on news.ycombinator.com