[Issue 19916] union member access should be un- at safe
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Fri May 31 21:31:08 UTC 2019
https://issues.dlang.org/show_bug.cgi?id=19916
--- Comment #10 from Manu <turkeyman at gmail.com> ---
(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
--
More information about the Digitalmars-d-bugs
mailing list