Warning: Some posts on this platform may contain adult material intended for mature audiences only. Viewer discretion is advised. By clicking ‘Continue’, you confirm that you are 18 years or older and consent to viewing explicit content.
I don’t speak C, but isn’t this an extreme simplification of the issue? I thought memory could be abused in an almost infinite number of subtle ways outside of allocating it wrong. For example, improperly sanitized string inputs. I feel like if it were this easy, it would have been done decades ago.
I think this can be explained by underlining the differences between could, would, and should.
The blog states the fact that at least some C compilers already offer the necessary and sufficient tools that characterize “memory-safe” languages, and proceeds to illustrate examples. This isn’t new. However, just like “memory-safe” languages enforce narrow coding styles through a happy path that is expected to prevent the introduction of some classes of vulnerabilities, leveraging these compiler features in C projects also requires the same type of approach.
This isn’t new or unheard of. Some C++ frameworks are also known for supporting their own memory management and object ownership strategies, but you need to voluntarily adhere to them.
I don’t speak C, but isn’t this an extreme simplification of the issue? I thought memory could be abused in an almost infinite number of subtle ways outside of allocating it wrong. For example, improperly sanitized string inputs. I feel like if it were this easy, it would have been done decades ago.
Buffer overflows are far from the only way for improperly sanitized inputs to be a problem
Use after free, null pointer dereference, double free.
Solutions to these in C end up looking a lot like Rust.
Yes. If you disabled unions and pointer casts, basically no C code would compile.
I think this can be explained by underlining the differences between could, would, and should.
The blog states the fact that at least some C compilers already offer the necessary and sufficient tools that characterize “memory-safe” languages, and proceeds to illustrate examples. This isn’t new. However, just like “memory-safe” languages enforce narrow coding styles through a happy path that is expected to prevent the introduction of some classes of vulnerabilities, leveraging these compiler features in C projects also requires the same type of approach.
This isn’t new or unheard of. Some C++ frameworks are also known for supporting their own memory management and object ownership strategies, but you need to voluntarily adhere to them.