Talk:Memory safety

advertising for SLIMalloc

I don't have time to pursue this, but as a person who works in the field: The SLIMalloc papers are completely free of important details, and no one I know working in the field believes it can actually do all the things it claims to do with the performance characteristics described, and the writing about it in those papers strongly suggests the author has no idea what's going on. It seems really weird to have these strong sweeping claims that precisely duplicate the claims from the papers published to promote the thing, but that have no sources other than the promotional material from the authors or things derived from them. This seems highly suspicious. — Preceding unsigned comment added by Wikiseebs (talk • contribs) 01:30, 19 March 2023 (UTC)

Strongly agree. The papers are scientifically worthless, make baseless near-impossible claims and would not pass peer review anywhere.

Nb, an IP from Switzerland (definetly not self-advertising from that Swiss company) keeps re-adding this ridiculous garbage after removal... RentABug (talk) 11:50, 11 April 2023 (UTC)

I agree, too. It's really frustrating to see someone [1] keep re-adding the same bogus claims, and try to deceive people who are just trying to learn about computer science. KramerCosmonaut (talk) 06:35, 20 April 2023 (UTC)

To provide some extra context, it is not possible for a malloc/free implementation to give memory safety to a memory-unsafe language as it is very easy to write a program with memory access violations which never calls malloc at any point. KramerCosmonaut (talk) 06:42, 20 April 2023 (UTC)

I'd also like to register this as a concern. I edited this out twice about a month ago, forgot about it, and then found an email in my inbox today accusing me of being KramerCosmonaut. The user at that IP address has posted a substantively equivalent version of the email on their talk page. Yossarian flew (talk) 06:49, 26 April 2023 (UTC)

"security vulnerabilities" section

Some of the sentences in the "security vulnerabilities" section are incoherent, others are just wrong. For example, a stack overflow is nothing like a buffer overflow, despite the vague note about them being "similar". I'll clean it up when I get a moment. Just thought I'd make a record of it here for now. 86.128.230.251 (talk) 22:51, 10 October 2011 (UTC)

I've restructured and improved the page a bit. I changed "security vulnerabilities" to "memory errors" because some of them are not exploitable. --Crashie (talk) 13:37, 27 November 2011 (UTC)

Michael Hicks

He has something to say on this article's definitions: http://www.pl-enthusiast.net/2014/07/21/memory-safety/ --Nemo 21:21, 30 October 2014 (UTC)

No mention of Rust and similar solutions

The article only states that most high-level languages use tracing garbage collection to avoid memory safety problems. We should mention that some languages, like Rust, use static analysis to fix the problem without having to rely on garbage collection. Munksgaard (talk) 10:20, 31 May 2015 (UTC)

External links modified (January 2018)

Hello fellow Wikipedians,

I have just modified one external link on Memory safety. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20150203130856/https://www.allinea.com/user-guide/DDTMemoryDebugging.html to https://www.allinea.com/user-guide/DDTMemoryDebugging.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 15:47, 25 January 2018 (UTC)

This is a stub.

This article is extremely short, and the subject itself is a multidimensional whopper. As such this article should be marked as a stub. The fact that there is only one mention of Rust before getting to the article citations is solid evidence that this is a stub. This article is highly incomplete and in serious need of being fleshed out. Comiscuous (talk) 01:48, 18 May 2021 (UTC)

I agree! There needs to be a list of languages, as there are a lot of them Amanita9564 (talk) 01:20, 26 December 2023 (UTC)

Concur. I will mark this as a stub. Are people interested in working on improving this? I would be willing to contribute to an improved article here with others. Yossarian flew (talk) 17:41, 4 February 2024 (UTC)

India Education Program course assignment

This article was the subject of an educational assignment at College Of Engineering Pune supported by Wikipedia Ambassadors through the India Education Program during the 2011 Q3 term. Further details are available on the course page.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 20:09, 1 February 2023 (UTC)

Memory Leaks Aren't an Example of Memory Unsafety

Hello! I'm a practitioner who is (somewhat) responsible for the supporting other software engineers in using memory-safe languages and is deeply familiar with the Rust programming language. This article's inclusion of memory leaks as a type of memory error (introduced in this edit) is incorrect. Here's why:

1. The ISRG does not consider memory leaks to be an example of memory unsafety.
2. MITRE, through CWE-699, does not include anything approaching "memory leaks" in the sections titled "Memory Buffer Errors" or "Pointer Issues". The currently cited CWE-633 is deprecated.
3. One of the existing citations listed on the page also indicate that leaks and errors are different. If leaks were errors, surely Valgrind's documentation would not repeat itself in the title!
4. Expanding the definition of "memory unsafety" to include "leaking memory" would mean that every commonly used, memory-safe language today (such as Python or Java) are memory unsafe. This is, to put it bluntly, silly: while leaking memory is a defect, it is not a defect that can lead to exploit.

Consequently, this page incorrectly defines "memory leak" incorrectly (the examples for "memory" leak are also, therefore, incorrect). For example:

1. Memory leaks do not only occur when memory usage is not tracked or is tracked incorrectly—they occur when the memory is not freed despite no longer being needed.
2. Stack overflows ("Stack Exhaustion" as used in the article) are not the result of memory leaks. The stack bound may be exhausted, but the stack memory might still be needed!
3. Heap exhaustion is sometimes a consequence of a memory leak, but it is not, in of itself, a memory leak.
4. Double, invalid, or mismatched frees are not a form of memory leaks: they are a form of memory corruption.
5. Unwanted aliasing is not a memory leak. Depending on the programming language's operational semantics, this is either logical bug or undefined behavior.

Endsofthreads (talk) 17:56, 30 September 2024 (UTC)

@Endsofthreads: I agree in every aspect so feel free to edit this article. See also this related discussion. Dexxor (talk) 16:27, 2 October 2024 (UTC)