2 ms·

> Memory Safety Is Easy In C++ It's just increasingly hard to even bother reading stuff like this nowadays. I feel like some people need to hear "you're not as

by k8svet 3y ago

> Memory Safety Is Easy In C++ It's just increasingly hard to even bother reading stuff like this nowadays. I feel like some people need to hear "you're not as good at writing memory safe code as you think, and even if you were, it doesn't make you a better person". It's okay to want better tools. It's okay to admit humans, even your own self, make or are capable of making mistakes.

gary_0 3y ago
Memory safety in C++ would be easy if everyone everywhere used std::vector.at(), avoided all manual memory management, only used safe libraries, and enabled the tooling that fails builds if any C-isms (like implicit casts) are used. That's never going to happen, though. Modern C++ does give you some nice foot armor, but (and I say this as a grudging C++ developer) that's no match for Rust's policy of taking away your footgun by default.
- olliej 3y ago
  And also don’t use “modern” features like string_view that are memory unsafe by _design_.
shrimp_emoji 3y ago
> It's okay to want better tools. It's okay to admit humans, even your own self, make or are capable of making mistakes. In abstract? Sure. As a pretext for surrendering to mediocrity and a ride to hell with a tank full of good intentions? Never!
hgs3 3y ago
> It's okay to want better tools. Based on the article I think that "better tool" is the fuzzer. As it points out remote exploits are overwhelmingly caused by bad input validation. These sorts of bugs can be found with fuzzing. Even if you're using a "memory safe" language you should still be fuzzing because uncaught exceptions and panics are bugs and improperly recovering from one without sanitizing state could lead to a security hole. Incidentally, as the article notes, the CVE reports we keep hearing about are coming from Microsoft and Google. One has to wonder whether this speaks more about these companies priorities than the tech. Do consider that it wasn't until Heartbleed that these companies finally decided to devote serious resources to the OpenSSL project. Do note that Heartbleed was discoverable with a fuzzer.
- k8svet 3y ago
  This exact conversation has been had in over 50% of every rust thread here, and a sibling comment makes the point well, and indeed it's the same wrong intimation as the article. It's lipstick on a pig. > One has to wonder whether this speaks more about these companies priorities than the tech. I am so, so very tired of this psuedo intellectual, open ended, conspiratorial nothing statements that are vague and meaningless. Is Torvalds in on it? The White House? Oxide? Chromium? Android? Maybe Rust folks are infiltrating C projects and writing bad code on purpose.
fargle 3y ago
> Memory Safe Is Easy In C++ > I feel like some people need to hear "you're not as good at writing memory safe code as you think both equally wrong. and it's _fine_ to want better tools. but we need to use the right tool for the job. doing something that involves lots of dynamic allocation and ownership and especially strings might be very hard to do in a memory-safe fashion in C or C++ but conversely there are plenty of other kinds of code that actually are "easy" to write, and verify, to be memory safe. to assert that language A is overall "better" or even just "safer" then language B without knowing the details is presumptuous. [to be clear TFA is highly presumptuous too]

by k8svet 3y ago

gary_0 3y ago

Memory safety in C++ would be easy if everyone everywhere used std::vector.at(), avoided all manual memory management, only used safe libraries, and enabled the tooling that fails builds if any C-isms (like implicit casts) are used. That's never going to happen, though. Modern C++ does give you some nice foot armor, but (and I say this as a grudging C++ developer) that's no match for Rust's policy of taking away your footgun by default.

olliej 3y ago
And also don’t use “modern” features like string_view that are memory unsafe by _design_.

shrimp_emoji 3y ago

> It's okay to want better tools. It's okay to admit humans, even your own self, make or are capable of making mistakes. In abstract? Sure. As a pretext for surrendering to mediocrity and a ride to hell with a tank full of good intentions? Never!

hgs3 3y ago

> It's okay to want better tools. Based on the article I think that "better tool" is the fuzzer. As it points out remote exploits are overwhelmingly caused by bad input validation. These sorts of bugs can be found with fuzzing. Even if you're using a "memory safe" language you should still be fuzzing because uncaught exceptions and panics are bugs and improperly recovering from one without sanitizing state could lead to a security hole. Incidentally, as the article notes, the CVE reports we keep hearing about are coming from Microsoft and Google. One has to wonder whether this speaks more about these companies priorities than the tech. Do consider that it wasn't until Heartbleed that these companies finally decided to devote serious resources to the OpenSSL project. Do note that Heartbleed was discoverable with a fuzzer.

k8svet 3y ago
This exact conversation has been had in over 50% of every rust thread here, and a sibling comment makes the point well, and indeed it's the same wrong intimation as the article. It's lipstick on a pig. > One has to wonder whether this speaks more about these companies priorities than the tech. I am so, so very tired of this psuedo intellectual, open ended, conspiratorial nothing statements that are vague and meaningless. Is Torvalds in on it? The White House? Oxide? Chromium? Android? Maybe Rust folks are infiltrating C projects and writing bad code on purpose.

fargle 3y ago

> Memory Safe Is Easy In C++ > I feel like some people need to hear "you're not as good at writing memory safe code as you think both equally wrong. and it's _fine_ to want better tools. but we need to use the right tool for the job. doing something that involves lots of dynamic allocation and ownership and especially strings might be very hard to do in a memory-safe fashion in C or C++ but conversely there are plenty of other kinds of code that actually are "easy" to write, and verify, to be memory safe. to assert that language A is overall "better" or even just "safer" then language B without knowing the details is presumptuous. [to be clear TFA is highly presumptuous too]