https://issues.dlang.org/show_bug.cgi?id=19916
--- Comment #10 from Manu <[email protected]> --- (In reply to Dennis from comment #7) > (In reply to Manu from comment #6) > > Accessing uninitialised memory is absolutely a memory safety issue. > > Not per se. This compiles, prints a random number, and doesn't corrupt > memory. > > ``` > import std; > > void main() @safe > { > int a = void; > writeln(a); > } > ``` Hah, well that's obviously broken too! > > I don't know where this idea that it has strictly to do with pointers comes > > from? > > Why would safety be limited that way? > > Paraphrasing Walter from his DConf 2017 keynote, memory safety is not about > 'no memory related bugs', it's "a concern in software development that aims > to avoid software bugs that cause security vulnerabilities dealing with > random-access memory (RAM) access, such as buffer overflows and dangling > pointers". Uninitialized / overlapped pointers can cause such issues, > uninitialized integers can not. Accessing uninitialised int's (as above) is possibly the most accessible form ob buffer overflow I can imagine. > Disallowing a simple harmless sum-type in @safe invites more use of @trusted > giving more opportunities for actual memory corrupting bugs to creep in. Not > to mention it would break existing code. It's not harmless at all, interaction with uninitialised memory is *the most critical form of safety error I can imagine*. If I were searching for exploits, that's where I would start every time. > Unless there is a way to actually corrupt memory in @safe code using this > (without using @trusted) it's not something @safe should prevent. int x = void; array[x]; // boom --
