this post was submitted on 13 Mar 2025
611 points (95.4% liked)
linuxmemes
23532 readers
409 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. ๐ฌ๐ง Language/ัะทัะบ/Sprache
- This is primarily an English-speaking community. ๐ฌ๐ง๐ฆ๐บ๐บ๐ธ
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed. ย
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I suppose we need to make definitions clearer. C++ is memory safe in the sense that you can write memory safe code. It doesn't enforce memory safety though. But not doing that is not the language's fault. If someone jumps with a bike from a flying airplane, it's not the bike's fault that they will not land safely. It's the misuse of the bike.
I'd argue those weren't the best developers then. However, I don't want to get ridiculous. I see that there are problems in the common use of C++. Although I can't share that from my experience due to usually proper usage, thorough testing use of additional tools, there is surely a need for aiding C++ devs with writing safe code. I know of the corresponding security concerns as well as probably everyone else in the C++ community.
There are proposals to improve on that. Some of those might already come with C++26. Stroustrup's favourite are Profiles to provide and enforce further guarantees, while others propsed an extension like Safe C++. Whereever the future will take us with C++, I'm confident that this issue will be sufficiently solved one day.
There was a time when C++ wasn't even designed for multi-processor systems, lol. That was redesigned pretty late. Much has changed and it will continue to improve as C++ continues to mature.
Edit: Just saw your convention examples after I've sent my reply. Idk why it wasn't displayed before.
Regarding the double free: It's clear from the documentation that this returns a raw pointer.
Regarding the use after free:
I really don't want to sound arrogant as this is a simple example of course, but that is such an obvious mistake and looks like a topic which is covered in C++ beginner classes. To me, this is almost on the same level as dividing by zero and wondering about resulting bugs.
Yes. Not every language is as user-friendly as python. With more flexibility come more risks but also more rewards if you've mastered it. It depends on what you want to do and how much you're willing to invest. I would at least expect a professional dev to rtfm. Which itself is apparently already a problem. But, in the end of the day we want to use tools, which are effective and easy to use. So sure, point taken. I refer to the section before my edit regarding developments upon improving such aspects in C++.
saying that C++ is memory safe because it's possible to use it in a memory safe manner is like saying jumping out of a plane with the bike is safe, because it's possible to safely land (with a parachute and a lot of training).
you always repeat that C++ is memory safe because its possible, and that "misuse" is "not its fault".
first, you are quite simply redefining what does memory safety mean. you basically say bombs are safe because they can be safely defused with the expertise.
second, do you really need to misuse it to get unsafe code? it does not warn anywhere. not in the instructions, not in the compiler output.
third, its no one's "fault" that c++ is not memory safe. That's not a fault of c++. like its not a fault of factories that you have to wear safery gear when working inside because otherwise you may get injured more severely. this is just a property of C++, not a judgement
oh no, my suspension was correct, you are really thinking that you are the perfect coder who jever makes any mistakes. It does not make sense to argue with you
The definition of "a memory safe programming language" is not in debate at all in the programming community. I have no idea why you're trying to change it.
This is incredibly arrogant, and, tbh, ignorant.
You missed the point of the examples: those aren't necessarily "easy mistakes" to make and of course a UAF is easy to spot in a 4 line program, the point is that there is no language construct in place to protect from these trivial memory safety issues. With respect to the "obviousness" of the
std::stringmistake, if you instead consider an opaque interface that requires aconst char*as an input, you have no idea if it is going to try to reference of that pointer or not past the lifetime of thestd::string. If you can't see past the simplicity of an example to the bigger picture that's not on me.