5 ms·

Well, not every construct in C can have safety issue. Saying that every line in C may be the source of memory safety issues is as accurate as saying that every

by uecker 2y ago

Well, not every construct in C can have safety issue. Saying that every line in C may be the source of memory safety issues is as accurate as saying that every line of Rust may be a source of memory safety issues, because it could make use of unsafe. There is another issue: Unsafe code in Rust could violate assumptions that could cause other code in Rust to be unsafe. So it needs more care to write than regular C. But I agree that it still a huge net benefit with respect to memory safety, but let's not exaggerate.

itishappy 2y ago
Those unsafe lines in C could be anywhere in your program. In Rust they cannot exist outside of unsafe blocks. This is not a trivial distinction! For all intents and purposes, each and every line of C must be treated as potentially unsafe.
adgjlsfhk1 2y ago
The really big difference is the searchability and frequency of possibly unsafe operations. If you want to audit all possible unsafe lines of code in a Rust project, you can grep for "unsafe" and find all of them (and in most projects there will be very few if any). In C, on the other hand, you need to look at literally every indexing operation, every pointer dereference, every use of a variable (to make sure it isn't potentially used after free or before initialization), every cast, and probably some extras that I've forgotten. As such, rather than having a low double digit number of cases to look at, you have to look at the vast majority of lines of code.
- uecker 2y ago
  While true, my point is that you can write C in a way that many functions are also obviously free of UB, and you only need to carefully vet the pointer arithmetic in some low-level functions. So I agree with the point in principle, I just do not like the "spin" of "every line of C is time bomb nobody can understand" while in Rust you just have to look at some lines of "unsafe" and all is good.
  - AlotOfReading 2y ago
    It's not my experience that C can be obviously free of UB and I'm curious to know how you approach that. I'm not aware of any methods or tools that claim to achieve it and there's a long history of "correct" programs written by experts were discovered to contain subtle UB with improvements in automated analysis. Here's one example, from Runtime Verification: https://runtimeverification.com/blog/mare-than-14-of-sv-comps-correct-programs-are-undefined https://runtimeverification.com/blog/mare-than-14-of-sv-comp...
    - uecker 2y ago
      For example, the following function has obviously no UB: unsigned int mul(unsigned int x, unsigned int y) { return x * y; } Or there are many high level function structures as, which also has no UB (with some assumption on the called functions): void bar() { struct foo *p = foo_alloc(); foo_do1(p); foo_do2(p); foo_delete(p); } Such code can be easily screened and also this can be done automatically. There is a lack of open-source which can do this, but I have an experimental GCC branch which starts to do this and looks promising.
      - AlotOfReading 2y ago
        The first has no UB, but this trivial modification does: unsigned short mul(unsigned short x, unsigned short y) { return x * y; } I don't know about you, but I wouldn't think to treat these any differently unless I put on my language lawyer hat.
        uecker 2y ago
        It is converted to int, so you have a signed multiplication. I don't think you need be a language lawyer to know this, just very basic C. But I also do not worry about signed overflow anyhow, because compilers can turn them into traps.
        AlotOfReading 2y ago

by uecker 2y ago

itishappy 2y ago

Those unsafe lines in C could be anywhere in your program. In Rust they cannot exist outside of unsafe blocks. This is not a trivial distinction! For all intents and purposes, each and every line of C must be treated as potentially unsafe.

adgjlsfhk1 2y ago

The really big difference is the searchability and frequency of possibly unsafe operations. If you want to audit all possible unsafe lines of code in a Rust project, you can grep for "unsafe" and find all of them (and in most projects there will be very few if any). In C, on the other hand, you need to look at literally every indexing operation, every pointer dereference, every use of a variable (to make sure it isn't potentially used after free or before initialization), every cast, and probably some extras that I've forgotten. As such, rather than having a low double digit number of cases to look at, you have to look at the vast majority of lines of code.

uecker 2y ago
While true, my point is that you can write C in a way that many functions are also obviously free of UB, and you only need to carefully vet the pointer arithmetic in some low-level functions. So I agree with the point in principle, I just do not like the "spin" of "every line of C is time bomb nobody can understand" while in Rust you just have to look at some lines of "unsafe" and all is good.
- AlotOfReading 2y ago
  It's not my experience that C can be obviously free of UB and I'm curious to know how you approach that. I'm not aware of any methods or tools that claim to achieve it and there's a long history of "correct" programs written by experts were discovered to contain subtle UB with improvements in automated analysis. Here's one example, from Runtime Verification: https://runtimeverification.com/blog/mare-than-14-of-sv-comps-correct-programs-are-undefined https://runtimeverification.com/blog/mare-than-14-of-sv-comp...
  - uecker 2y ago
    For example, the following function has obviously no UB: unsigned int mul(unsigned int x, unsigned int y) { return x * y; } Or there are many high level function structures as, which also has no UB (with some assumption on the called functions): void bar() { struct foo *p = foo_alloc(); foo_do1(p); foo_do2(p); foo_delete(p); } Such code can be easily screened and also this can be done automatically. There is a lack of open-source which can do this, but I have an experimental GCC branch which starts to do this and looks promising.
    - AlotOfReading 2y ago
      The first has no UB, but this trivial modification does: unsigned short mul(unsigned short x, unsigned short y) { return x * y; } I don't know about you, but I wouldn't think to treat these any differently unless I put on my language lawyer hat.
      - uecker 2y ago
        It is converted to int, so you have a signed multiplication. I don't think you need be a language lawyer to know this, just very basic C. But I also do not worry about signed overflow anyhow, because compilers can turn them into traps.
        AlotOfReading 2y ago