Earlier quoted context omitted.
Except, you've failed to check for an error, and you need another line to do that. Suppose the user ended their input or the input is a pipe that's been closed - what does your C++ program do? Here's another example. C++ lets you do this: long input; std::cin >> input; process(input); and this is very convenient! It's much shorter than the Rust code for doing the same. It's also wrong! If the input cannot be read, or…
> Some people will say, I just want to get stuff done and not worry about all this safety junk. As someone who works in security and have exploited bugs in C/C++ programs, this is pretty much why we wound up with so many CVEs. Are constructions like these really the root cause of CVEs? As long as you do a correct check, then you're all good. If Rust can do the same thing in fewer lines, then that may or may not be a…
“An issue was discovered in slicer69 doas before 6.2 on certain platforms other than OpenBSD. On platforms without strtonum(3), sscanf was used without checking for error cases. Instead, the uninitialized variable errstr was checked and in some cases returned success even if sscanf failed. The result was that, instead of reporting that the supplied username or group name did not exist, it would execute the command as root.”
Fail to check that your input parsed correctly, wind up with privilege escalation to root.