6 ms·

Wouldn't it be possible to have a C-like language that is somewhat backward compatible with C, and have the nice security features of Rust? I get that Rust is

by jokoon 6y ago

Wouldn't it be possible to have a C-like language that is somewhat backward compatible with C, and have the nice security features of Rust? I get that Rust is awesome, but I'm not certain you need to make an entire new language just to have the security stuff. Of course it might be complicated to do, but in the end, aren't there linters or other validators that can give the same security results rust has, but with C or even C++?

jdub 6y ago
1. You could possibly get closer, but you'd lose a lot. Most of Rust's "nice security features" are wildly incompatible with existing C/C++ code and inherent language features. 2. No. If C/C++ could be made safe* Rust would not exist. * everyone agrees on this point, including the richest and largest software companies on the planet
- dependenttypes 6y ago
  > Most of Rust's "nice security features" are wildly incompatible with existing C/C++ code and inherent language features Such as?
  - fhars 6y ago
    Lifetimes and the borrow checker.
    - dependenttypes 6y ago
      A linter can do that.
      - smolder 6y ago
        Nope.
        dependenttypes 6y ago
        Just because you lack the ability to imagine something like that it does not mean that it is impossible. Sadly this kind of sentiment seems to be way too common in tech.
        SAI_Peregrinus 6y ago
        C lacks the information given to the compiler to do this. It can't be added without adding that to the language. So no linter can do this alone, without language changes.
        dependenttypes 6y ago
        You can use _Pragma/#pragma, regardless though, you can achieve a lot of what lifetimes can without any annotation.
        SAI_Peregrinus 6y ago
        Pragmas are extensions to C, not part of the C language standard. You can add things to C, but it then ceases to be standard C and becomes GNU C or MS Visual C or early C++ or something else. But not ISO Standard C. And yes, just about anything non-lexical lifetimes can do you can do with static analysis. But the set of things you can do with Rust includes things that need explicit lifetime annotations, which C doesn't have.
        smolder 6y ago
        It is impossible given the spec and syntax of those languages, which is why Rust exists, to enable these features...
        pirocks 6y ago
        This wouldn't be possible in a practical sense. One could imagine a static analyzer of some kind which infers all lifetimes, though that would likely quickly be unworkably slow on real codebases, since you need to infer programmer intent. Additionally c static analyzers intended to catch all memory errors/UB etc. have existed for decades, and no one uses them, b/c they don't work or have too many false positives. For example did you know that until C++20 allocating an int with malloc was UB in C++? Would you want to work in a language where the linter marked every other line as UB?
server_bot 6y ago
These are valid questions a lot of people new to Rust have, so: 1. Rust is "backward compatible" in the sense that Rust code can use C libraries and C code can use Rust libraries - both ways via CFFI [1]. Security gaurentees only apply to the Rust code. 2. We've tired static and dynamic analysis of C to find security bugs for decades, there has been a plethora of research and commercial tools in the space. None fix the problem like Rust does [2]. [1] https://michael-f-bryan.github.io/rust-ffi-guide/ https://michael-f-bryan.github.io/rust-ffi-guide/ [2] https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/ https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...
- blub 6y ago
  Almost any language can call C functions and we don't call all languages backwards compatible with C when they can merely interoperate with it. Objective-C and C++ are the only two languages which offer backwards compatibility. AFAIK it's complete in the case of the former and there are some limitations for the latter. None fix the problem like Rust does, but it's worthwhile to examine why: typical companies and developers have an aversion to paying for tools and for anything which slows down development. That's why usually those tools and languages which are reasonably user-friendly are more successful. Ironically that's both an advantage and a problem for rust: it's nicer to use than some C tools, but still not user-friendly compared to alternatives like Go or Java and in some cases even C++.
dependenttypes 6y ago
You certainly do not even need to make a new language. Just making a new C implementation that aborts on buffer overflows for example would be enough.
- sanxiyn 6y ago
  This is an intractable problem because checking for buffer overflows requires buffer bounds and C pointers lack buffer bounds. Rust solves this by "fat pointer", pointer that knows its size, but fat pointer can't be the same size as thin pointer hence it would be backward incompatible.
  - dependenttypes 6y ago
    Your C implementations lacks "buffer bounds". C by itself doesn't. There is nothing stopping a C implementation tracking the size of the data that a pointer points to (and these implementations are not even hypothetical, they actually exist right now). > hence it would be backward incompatible Rust is backward incompatible with C. A C implementation with fat pointers would not be backward incompatible with C. Depending on how it was implemented it could be ABI-incompatible with older C implementations but this is not necessary either.
    - pirocks 6y ago
      The problem fat pointer based implementations are massively slower. Rust aims to provide safety without massive performance penalties. If one wanted safety without performance they would just use java or similar.
      - dependenttypes 6y ago
        > The problem fat pointer based implementations are massively slower I am challenging that. I do not believe that a C implementation that uses fat pointers needs to be any slower than Rust. > If one wanted safety without performance they would just use java or similar. Or C with a safe implementation.
deleted 6y ago
[deleted]
pornel 6y ago
There is Cyclone, Checked C, Deputy. Such "C-but-weird" languages have an "uncanny valley" problem: • "C, but safer" on its own is not very enticing. With no other benefits, it's easy not to switch, and instead promise to try harder writing standard C safely, or settle for analysis tools or sandboxes. • People who use C often have backwards compatibility constraints. Switching to another compiler and a dialect that isn't standard C is a tough sell. You can still find C programmers who think adopting C99 is too radical. • Programming patterns commonly used in C (rich in pointer juggling, casts, and textual macros) are inherently risky, but if you try to replace them (e.g. with generics, iterators), it stops looking like C anyway. So "safer C" is unattractive to people who are tied to C implementations or don't want to learn a new language. But people who do want to learn a new language and use modern tooling, don't want all the unfixable legacy baggage of C. Rust dodges these problems by not being a "weird C". It's a clean design, with enough features to be attractive on its own, and safety is just a cherry on top.
- jokoon 6y ago
  Sounds like marketing to me. It will convince young, gullible CS students, but not software engineers.
- Nuoji 6y ago
  Cyclone was not fully realized though. And there are languages that try to keep to C and add some minor safety improvements, eg my language C3 (subarrays/slices, contracts, all UB has runtime checks in debug builds and more)
qppo 6y ago
I think maybe you're conflating what Rust's borrow checker does with the notion of "security." They're related in that the borrow checker does some stuff that makes it difficult to create certain bugs that can be security issues, but they're not the same. But to answer the question, I suspect no, and if you did it would be basically re-engineering the borrow checker and forcing Rust semantics into C and C++. I don't know if anyone has proven it, but my hunch is that borrow checking C is undecidable.

by jokoon 6y ago

jdub 6y ago

1. You could possibly get closer, but you'd lose a lot. Most of Rust's "nice security features" are wildly incompatible with existing C/C++ code and inherent language features. 2. No. If C/C++ could be made safe* Rust would not exist. * everyone agrees on this point, including the richest and largest software companies on the planet

dependenttypes 6y ago
> Most of Rust's "nice security features" are wildly incompatible with existing C/C++ code and inherent language features Such as?
- fhars 6y ago
  Lifetimes and the borrow checker.
  - dependenttypes 6y ago
    A linter can do that.
    - smolder 6y ago
      Nope.
      - dependenttypes 6y ago
        Just because you lack the ability to imagine something like that it does not mean that it is impossible. Sadly this kind of sentiment seems to be way too common in tech.
        SAI_Peregrinus 6y ago
        C lacks the information given to the compiler to do this. It can't be added without adding that to the language. So no linter can do this alone, without language changes.
        dependenttypes 6y ago
        You can use _Pragma/#pragma, regardless though, you can achieve a lot of what lifetimes can without any annotation.
        SAI_Peregrinus 6y ago
        Pragmas are extensions to C, not part of the C language standard. You can add things to C, but it then ceases to be standard C and becomes GNU C or MS Visual C or early C++ or something else. But not ISO Standard C. And yes, just about anything non-lexical lifetimes can do you can do with static analysis. But the set of things you can do with Rust includes things that need explicit lifetime annotations, which C doesn't have.
        smolder 6y ago
        It is impossible given the spec and syntax of those languages, which is why Rust exists, to enable these features...
        pirocks 6y ago
        This wouldn't be possible in a practical sense. One could imagine a static analyzer of some kind which infers all lifetimes, though that would likely quickly be unworkably slow on real codebases, since you need to infer programmer intent. Additionally c static analyzers intended to catch all memory errors/UB etc. have existed for decades, and no one uses them, b/c they don't work or have too many false positives. For example did you know that until C++20 allocating an int with malloc was UB in C++? Would you want to work in a language where the linter marked every other line as UB?

server_bot 6y ago

These are valid questions a lot of people new to Rust have, so: 1. Rust is "backward compatible" in the sense that Rust code can use C libraries and C code can use Rust libraries - both ways via CFFI [1]. Security gaurentees only apply to the Rust code. 2. We've tired static and dynamic analysis of C to find security bugs for decades, there has been a plethora of research and commercial tools in the space. None fix the problem like Rust does [2]. [1] https://michael-f-bryan.github.io/rust-ffi-guide/ https://michael-f-bryan.github.io/rust-ffi-guide/ [2] https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/ https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

blub 6y ago
Almost any language can call C functions and we don't call all languages backwards compatible with C when they can merely interoperate with it. Objective-C and C++ are the only two languages which offer backwards compatibility. AFAIK it's complete in the case of the former and there are some limitations for the latter. None fix the problem like Rust does, but it's worthwhile to examine why: typical companies and developers have an aversion to paying for tools and for anything which slows down development. That's why usually those tools and languages which are reasonably user-friendly are more successful. Ironically that's both an advantage and a problem for rust: it's nicer to use than some C tools, but still not user-friendly compared to alternatives like Go or Java and in some cases even C++.

dependenttypes 6y ago

You certainly do not even need to make a new language. Just making a new C implementation that aborts on buffer overflows for example would be enough.

sanxiyn 6y ago
This is an intractable problem because checking for buffer overflows requires buffer bounds and C pointers lack buffer bounds. Rust solves this by "fat pointer", pointer that knows its size, but fat pointer can't be the same size as thin pointer hence it would be backward incompatible.
- dependenttypes 6y ago
  Your C implementations lacks "buffer bounds". C by itself doesn't. There is nothing stopping a C implementation tracking the size of the data that a pointer points to (and these implementations are not even hypothetical, they actually exist right now). > hence it would be backward incompatible Rust is backward incompatible with C. A C implementation with fat pointers would not be backward incompatible with C. Depending on how it was implemented it could be ABI-incompatible with older C implementations but this is not necessary either.
  - pirocks 6y ago
    The problem fat pointer based implementations are massively slower. Rust aims to provide safety without massive performance penalties. If one wanted safety without performance they would just use java or similar.
    - dependenttypes 6y ago
      > The problem fat pointer based implementations are massively slower I am challenging that. I do not believe that a C implementation that uses fat pointers needs to be any slower than Rust. > If one wanted safety without performance they would just use java or similar. Or C with a safe implementation.

deleted 6y ago

[deleted]

pornel 6y ago

There is Cyclone, Checked C, Deputy. Such "C-but-weird" languages have an "uncanny valley" problem: • "C, but safer" on its own is not very enticing. With no other benefits, it's easy not to switch, and instead promise to try harder writing standard C safely, or settle for analysis tools or sandboxes. • People who use C often have backwards compatibility constraints. Switching to another compiler and a dialect that isn't standard C is a tough sell. You can still find C programmers who think adopting C99 is too radical. • Programming patterns commonly used in C (rich in pointer juggling, casts, and textual macros) are inherently risky, but if you try to replace them (e.g. with generics, iterators), it stops looking like C anyway. So "safer C" is unattractive to people who are tied to C implementations or don't want to learn a new language. But people who do want to learn a new language and use modern tooling, don't want all the unfixable legacy baggage of C. Rust dodges these problems by not being a "weird C". It's a clean design, with enough features to be attractive on its own, and safety is just a cherry on top.

jokoon 6y ago
Sounds like marketing to me. It will convince young, gullible CS students, but not software engineers.
Nuoji 6y ago
Cyclone was not fully realized though. And there are languages that try to keep to C and add some minor safety improvements, eg my language C3 (subarrays/slices, contracts, all UB has runtime checks in debug builds and more)

qppo 6y ago

I think maybe you're conflating what Rust's borrow checker does with the notion of "security." They're related in that the borrow checker does some stuff that makes it difficult to create certain bugs that can be security issues, but they're not the same. But to answer the question, I suspect no, and if you did it would be basically re-engineering the borrow checker and forcing Rust semantics into C and C++. I don't know if anyone has proven it, but my hunch is that borrow checking C is undecidable.