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), but 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.
This is of course not as good as ASAN or a borrow checker, but it interacts very nicely with C.
I would say that the title is easily misread. If you open the blog post and just read the title and a few lines into the intro, I think it's clear it's about 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.
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.
It should also be clear from the rest of the blog post that it doesn't try to make any claims that it's a novel technique (it's something that has been around for a long time). What's novel is that it's well integrated into the stdlib.
This is so fucking obnoxious. There is no misreading. There is not misunderstanding. Any attempt to spin this as even in part a failure of the reader is so rude.
The title is nonsense. Nobody is misreading it, the author was either willfully misleading for clicks (eww) or was just ignorant (excusable, but they need to own it).
> That is very unfortunate, but chance to fix that title already passed.
…the CMS doesn’t let them edit it? What nonsense is this.
This is a lovely example of what professional communication does NOT look like. Incredibly disingenuous all around.
(I’d love better arena syntax in more languages though. They don’t get enough support.)
Let me paste the introduction in the post, and let's see how much it claims that C3 has memory safety:
Modern languages offer a variety of techniques to help with dynamic memory management, each one a different tradeoff in terms of performance, control and complexity. In this post we’ll look at an old idea, memory allocation regions or arenas, implemented via the C3 Temp allocator, which is the new default for C3.
The Temp allocator combines the ease of use of garbage collection with C3’s unique features to give a simple and (semi)-automated solution within a manual memory management language. The Temp allocator helps you avoid memory leaks, improve performance, and simplify code compared to traditional approaches.
Memory allocations come in two broad types stack allocations which are compact, efficient and automatic and heap allocations which are much larger and have customisable organisation. Custom organisation allows both innovation and footguns in equal measure, let’s explore those.
> 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).
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.
This is of course not as good as ASAN or a borrow checker, but it interacts very nicely with C.