Item — HN Reader

Well, the title (which is poorly worded as has been pointed out) refers to C3 being able to implement good handling of lifetimes for temporary allocations by baking it into the stdlib. And so it doesn't need to reach for any additional language features. (There is for example a C superset that implements borrowing, but C3 doesn't take that route)

What the C3 solution DOES to provide a way to detect at runtime when already freed temporary allocation is used. That's of course not the level of compile time checking that Rust does. But then Rust has a lot more in the language in order to support this.

Conversely C3 does have contracts as a language feature, which Rust doesn't have, so C3 is able to do static checking with the contracts to reject contract violations at compile time, which runtime contracts like some Rust creates provides, can't do.

3 comments

> What the C3 solution DOES to provide a way to detect at runtime when already freed temporary allocation is used.

The article makes no mention of this, so in the context of the article the title remains very wrong. I could also not find a page in the documentation claiming this is supported (though I have to admit I did not read all the pages), nor an explanation of how this works, especially in relation to the performace hit it would result in.

> C3 is able to do static checking with the contracts to reject contract violations at compile time

I tries searching how these contracts work in the C3 website [1] and these seems to be no guaranteed static checking of such contracts. Even worse, violating them when not using safe mode results in "unspecified behaviour", but really it's undefined behaviour (violating contracts is even their list of undefined behaviour! [2])

[1]: https://c3-lang.org/language-common/contracts/

[2]: https://c3-lang.org/language-rules/undefined-behaviour/#list...

> The article makes no mention of this, so in the context of the article the title remains very wrong

The temp allocator implementation isn't guaranteed to detect it, and the article doesn't go into implementation details and guarantees (which is good, because capabilities will be added on the road to 1.0).

> I tries searching how these contracts work in the C3 website [1] and these seems to be no guaranteed static checking of such contracts.

No, there is no guarantee at the language level because doing so would make a conforming implementation of the compiler harder than it needs to be. In addition, setting exact limits may hamper innovation of compilers that wish to add more analysis but will hesitate to reject code that can be statically know to violate contracts.

At higher optimizations, the compiler is allowed to assume that the contracts evaluate to true. This means that code like `assert(i == 1); if (i != 1) return false;` can be reduced to a no-op.

So the danger here is then if you rely on the function giving you a valid result even if the indata is not one that the function should work with.

And yes, it will be optional to have those "assumes" inserted.

Already today in current compiler, doing something trivial like writing `foo(0)` to a function that requires that the parameter > 1 is caught at compile time. And it's not doing any real analysis yet, but it will definitely happen.

Just my opinion, but I think that having contracts that might be checked is a really really really dangerous approach. I think it is a much better idea to start with a plan for what sorts of things you can check soundly and only do those. "Well we missed that one because we only have intraprocedural constant propagation" is not going to be the sort of thing most users understand and will catch people by surprise.

Well, we've already tried that, and no one used it.

Safety is a spectrum. You add +1 and safety goes up.

> The temp allocator implementation isn't guaranteed to detect it, and the article doesn't go into implementation details and guarantees

Understandable, but then why are you mentioning the borrow checker if you avoided mentioning _anything_ that could be compared to it.

> No, there is no guarantee at the language level

Then don't go around claiming they are statically checked, that's false. What you have is a basic linter, not a statically enforced contract system.

Oof that sounds incredibly dangerous and basically means it doesn't really offer much of an improvement over C imo in terms of safety.

What is "incredibly dangerous"? Having contracts that can catch errors at compile time?

I understood your comment as that contracts are not statically checked at compile time. That is incredibly dangerous and means I would never go to bat for the language.

> What the C3 solution DOES to provide a way to detect at runtime when already freed temporary allocation is used.

I looked at the allocator source code and there’s no use-after-free protection beyond zeroing on free, and that is in no way sufficient. Many UAF security exploits work by using a stale pointer to mutate a new allocation that re-uses memory that has been freed, and zeroing on free does nothing to stop these exploits.

It doesn't zero on free, that's not what the code does. But if you're looking for something to prevent exploits, then no, this is not it, nor does it try to be.

How would you want that implemented?

> But if you're looking for something to prevent exploits, then no, this is not it, nor does it try to be.

> How would you want that implemented?

Any of the usual existing ways of managing memory lifetimes (i.e. garbage collection or Rust-style borrow checking) prevents that particular kind of exploitation (subject to various caveats) by ensuring you can't have a pointer to memory that has already been freed. So one would expect something that claims to solve the same problem to solve that problem.

All of that is out of scope for a C-like though. Once you set the constraints around C, there will be trade-offs. Rust is a high level language.

C on modern hardware/compilers has all the disadvantages of a high-level language (at least to the extent that Rust does).

That was already available in languages like Modula-2 and Object Pascal, as the blog post acknowledges the idea is quite old, and was also the common approach to manage memory originally with Objective-C on NeXTSTEP, see NSZone.

Hence why all these wannabe be C replacements, but not like Rust, should bring more to the table.