11 ms·

In my opinion, a runtime check is less safe than a compile time check. In both cases, the language is free from undefined behavior when using a freed reference.

by sumy23 4y ago

In my opinion, a runtime check is less safe than a compile time check. In both cases, the language is free from undefined behavior when using a freed reference. However, while a language with a runtime check might not have UB, programs written in this language might have UB. What happens in the program when the use-after-free happens? Depending on how the error is generated and propagated / handled, the program could end up in an undefined state. Programs written in safe Rust, however, will never have such undefined behavior

azakai 4y ago
Rust with RefCell will have such runtime errors, though. (Likewise, Rust using the indexes-in-an-array pattern can have use-after-free, but the harm is limited.) Also, IIUC this is not actually UB in Vale: it's a guaranteed error.
- sumy23 4y ago
  Yes it’s a guaranteed error in Vale, but the error may cause UB in the application logic. This won’t happen in Rust because the program won’t compile if a use-after-free is possible.
  - azakai 4y ago
    I wouldn't say it causes UB. It causes the problem to halt, deterministically, and safely - but maybe annoyingly. Yes, it's not as good as a static guarantee. But there are tradeoffs where it makes sense. Again, RefCell in Rust does the same - it's a useful technique.
  - imtringued 4y ago
    According to your definition everything is undefined behaviour. Imagine a simple program that successfully halts if it's input is empty and returns an error if it's input is no empty. C adds a third state undefined. When you reach this state you know nothing about what is happening in the program. Now Vale adds a third state called "memory error" which is just a refined error and well defined. This means that if you have handled the error case, you already handled the memory error case even if not in a satisfactory way. What is strange to me is that you consider the former okay and the latter undefined behaviour in the application logic when it just means that an additional exit state has been added which a highly defined behaviour.

by sumy23 4y ago

azakai 4y ago

Rust with RefCell will have such runtime errors, though. (Likewise, Rust using the indexes-in-an-array pattern can have use-after-free, but the harm is limited.) Also, IIUC this is not actually UB in Vale: it's a guaranteed error.

sumy23 4y ago
Yes it’s a guaranteed error in Vale, but the error may cause UB in the application logic. This won’t happen in Rust because the program won’t compile if a use-after-free is possible.
- azakai 4y ago
  I wouldn't say it causes UB. It causes the problem to halt, deterministically, and safely - but maybe annoyingly. Yes, it's not as good as a static guarantee. But there are tradeoffs where it makes sense. Again, RefCell in Rust does the same - it's a useful technique.
- imtringued 4y ago
  According to your definition everything is undefined behaviour. Imagine a simple program that successfully halts if it's input is empty and returns an error if it's input is no empty. C adds a third state undefined. When you reach this state you know nothing about what is happening in the program. Now Vale adds a third state called "memory error" which is just a refined error and well defined. This means that if you have handled the error case, you already handled the memory error case even if not in a satisfactory way. What is strange to me is that you consider the former okay and the latter undefined behaviour in the application logic when it just means that an additional exit state has been added which a highly defined behaviour.