this post was submitted on 13 Mar 2025
671 points (100.0% liked)
linuxmemes
23908 readers
1436 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++.
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.Yes, my mistake. I'm sorry.
You've willingly ignored the remaining part of that context, where I explicitly admitted problems in common usage. It was not my intention to come across as arrogant.
Depending on what you mean by "language constructs": there are, e.g. RAII or smart pointers. But they aren't enforced. So it's correct to say that C++ is inherently memory unsafe due to the lack of such enforcements. The discussions here changed my opinion about that.
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
This is incorrect. If you properly test your code such errors will become visible. It's not too much of an ask to conduct systematic software testing. You should do it anyway regardless of the language used.
You are quick with being judgemental and ignoring the rest of what I said in that part, which is why I agree with you. This discussion is no longer productive.
Ah, just as all the memory-mishandling related security issues in all operating systems out there. Nobody tests their shit well enough nowadays!
Quick??? Read all your other comments man! I take it as you not wanting to accept it.
I think there is indeed a lack of commitment. Thanks to capitalism and therefore production deadlines. Well, given, you can't always catch "all" potential bugs, not just memory related issues. That's sometimes not even theoretically possible. But it's no secret how software quality increases by testing it thouroughly. And a lot of the time I just don't see that happening. I've worked at institutions where software tests were done by answering the question "does it compile and run?". And I've experienced systematic tests with specialized test engineers, who still had to cut short a lot of the time. But to assume that software is always tested well enough is in my experience naive.
This is not helpful. If you have critique, be more specific. I know what I've written.
I am always open to discussion and changing my views if I see convincing arguments, as I did at another place here. Your lack of patience and quick judgement of my character is not my fault, but yours. I was discussing the issues here neutrally with you so far.
However, this topic is done for me anyway, as the discussions here did indeed change my view regarding memory safety in C++.