5 ms·

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 ba

by lerno 1y ago

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.

SkiFire13 1y ago
> 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/ https://c3-lang.org/language-common/contracts/ [2]: https://c3-lang.org/language-rules/undefined-behaviour/#list-of-undefined-behaviours https://c3-lang.org/language-rules/undefined-behaviour/#list...
- lerno 1y ago
  > 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.
  - UncleMeat 1y ago
    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.
    - lerno 1y ago
      Well, we've already tried that, and no one used it.
    - GoblinSlayer 1y ago
      Safety is a spectrum. You add +1 and safety goes up.
  - rowanG077 1y ago
    Oof that sounds incredibly dangerous and basically means it doesn't really offer much of an improvement over C imo in terms of safety.
    - lerno 1y ago
      What is "incredibly dangerous"? Having contracts that can catch errors at compile time?
      - rowanG077 1y ago
        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.
  - SkiFire13 1y ago
    > 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.
fanf2 1y ago
> 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.
- lerno 1y ago
  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?
  - lmm 1y ago
    > 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.
    - lerno 1y ago
      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.
      - lmm 1y ago
        C on modern hardware/compilers has all the disadvantages of a high-level language (at least to the extent that Rust does).
pjmlp 1y ago
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.

by lerno 1y ago

SkiFire13 1y ago

> 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/ https://c3-lang.org/language-common/contracts/ [2]: https://c3-lang.org/language-rules/undefined-behaviour/#list-of-undefined-behaviours https://c3-lang.org/language-rules/undefined-behaviour/#list...

lerno 1y ago
> 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.
- UncleMeat 1y ago
  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.
  - lerno 1y ago
    Well, we've already tried that, and no one used it.
  - GoblinSlayer 1y ago
    Safety is a spectrum. You add +1 and safety goes up.
- rowanG077 1y ago
  Oof that sounds incredibly dangerous and basically means it doesn't really offer much of an improvement over C imo in terms of safety.
  - lerno 1y ago
    What is "incredibly dangerous"? Having contracts that can catch errors at compile time?
    - rowanG077 1y ago
      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.
- SkiFire13 1y ago
  > 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.

fanf2 1y ago

> 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.

lerno 1y ago
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?
- lmm 1y ago
  > 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.
  - lerno 1y ago
    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.
    - lmm 1y ago
      C on modern hardware/compilers has all the disadvantages of a high-level language (at least to the extent that Rust does).

pjmlp 1y ago

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.