[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


--- 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