• 0 Posts
  • 12 Comments
Joined 1 year ago
cake
Cake day: June 22nd, 2023

help-circle
  • At least it appears to be something that gets triggered. In theory, if a node is not under attack or heavy usage, this isn’t a consideration. Doesn’t seem to be a perfect solution as it still slows the traffic of legitimate users in the event of an attack. I don’t know the full details, but in the worse case it makes it easier to semi-DoS, maybe not by fully making a node unresponsive, but by making the service so painfully slow that users may give up on it.












  • The short answer is Rust was built with safety in mind. The longer answer is C was built mostly to abstract from assembly without much thought to safety. In C, if you want to use an array, you must manually request a chunk of memory, check to make sure you are writing within the bounds of your array, and free up the memory used by your array when completely done using it. If you do not do those steps correctly, you could write to a null pointer, cause a buffer overflow error, a use-after-free error, or memory leak depending on what step was forgotten or done out of order. In Rust, the compiler keeps track of when variables are used through a borrowing system. With this borrowing system the Rust compiler requests and frees memory safely. It also checks array bounds at run-time without a programmer explicitly needing to code it in. Several high-level languages have alot of these safety features too. C# for example, can make sure objects are not freed until they fall out of scope, but it does this at run-time with a garbage collector where Rust borrower rules are done at compile-time.