4 ms·
How is that memory safe? Even vector out of bounds index is not memory safe.
by z_open 3y ago
How is that memory safe? Even vector out of bounds index is not memory safe.
- bun_terminator 3y agoYou can access a vector with a function that throws an exception if you so desire
- TwentyPosts 3y agoYou can also just write no code at all if you so desire. It certainly won't cause any memory issues that way. (Hint: What you yourself decide to write or refrain from writing is not the problem. You're not they only person who ever worked on this legacy codebase, and you want guarantees but default, not having to check every line of code in the entire project.)
- bun_terminator 3y agono you just have to write a githook with some static analysis, like literally everyone who does proper c++. Safety hasn't been an issue in c++ for more than a decade. It's just a made up thing by people who don't use the language but only want to hate.
- z_open 3y agoGo look at the CVEs and github issues of modern C++ codebases. Your statement is nonsense. Chromium is still plagued by use after free. How high do you set the bar? Which codebases are we allowed to look at?
- bun_terminator 3y agoI had that exact discussion with someone else a while ago. And when you actually go through the chromium memory bugs, it's 100% avoidable with an absolute baseline of competence and not using ancient bugs. It's unfair that C++ always has to compete in its state from 1990s against languages in their current iteration.
- z_open 3y agoThat's why I asked what the bar was? If Google is writing shitty C++ even with the world's eyes on their code base, who is doing it right? No one writing anything sufficiently complicated that's for sure.
- bun_terminator 3y agoHowever you feel about this issue: It's pretty widely known that google is bad at c++. Most codebases will be of significantly higher quality.
- hairyplanner 3y agoGoogle chrome must be one of the most used (in terms of CPU time) C++ software in the world right now. That means it's been fuzz tested (by the developers as well as by the users and also the random websites that gives it garbage html and javascript) extensively. I can only think of the Linux kernel that is more widely used, and Linux is not C++. Since you seem to be very good at c++, can you point to a "significantly higher quality" c++ projects please? I'd like to see what it looks like.
- delta_p_delta_x 3y ago> Since you seem to be very good at c++, can you point to a "significantly higher quality" c++ projects please? Not the parent commenter, but there are quite a few very high-quality C++ projects out there. - LLVM - KDE projects - CMake - Node.js - OpenJDK
- bun_terminator 3y agoI don't think popular or large correlate with code quality. In fact it's probably the opposite. It uses pretty ancient c++ stuff, which immediately disqualifies it from bring of high quality in regards to the cpp code (and also is the cause for their security bugs)
- TwentyPosts 3y ago
- evouga 3y agoIt's funny; I spent a couple of hours last week helping some students debug out-of-bounds indices in their Rust code. I've written bugs that would have been caught by the compiler in a memory-safe language. I think the last time was maybe in 2012 or 2013? I still write plenty of bugs today but they're almost all logic errors that nothing (short of AI tools) could have caught.
- bluGill 3y agovector.at() is memory safe. You get a choice. Easy to ban [] if you cannot statically prove it is safe. C++11 isn't the most memory safe language, but C++11 is a lot safer than older versions, and C++23 is better yet. I'm expecting true memory safety in C++26 (time will tell), but it will be opt-in profiles which isn't ideal.
- z_open 3y agoThis is not idiomatic C++ in any C++ standard. You can also just replace vector with map so the brackets insert, but that isn't either.
- bluGill 3y agoPrefer at to [] is standard where I write C++. map is not standard because vector is almost always much faster random access in the real world (that is n is normally small enough that a linear search is faster than a binary search because of caching)