[Issue 19916] union member access should be un- at safe

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=19916

--- Comment #15 from Dennis <dkorpel at live.nl> ---
(In reply to Manu from comment #14) 
> You're seriously going to suggest that allowing functional access to
> uninitialised memory is comparable to a for-loop... with a straight face?

Note that we are talking about union member access here, i.e. potential access
to garbage memory. Not guaranteed access to garbage memory. The constructs I
mentioned are all possible to use right, but common sources of bugs in C.

for (size_t i=length; i >= 0; i--) //endless loop because of unsigned underflow
for (int i=0; i < length; i++) // endless loop if > 2GB array
for (p = str; p; p++) // read past null-byte until segfault
int *a = tryFindPointer(); *a = 3; // possible null-dereference
struct Obj obj; useObj(&obj); // uninitialized object

While these bugs are also possible in D, in @safe code they won't result in
memory corruption, only in a segfault or range violation.

> How can you argue that feeding uninitialised memory into ANY transformation
> pipeline is @safe? 

@safe does not mean no bugs!
@safe is not the same as the English word 'safe'!
```
void main() @safe {
    int* a;
    *a = 3;
}
```
This is a bug.
Arguably it should give an error
It may not be 'safe', but it is '@safe' with its current definition.

Please mentally replace the term @safe with something like 'insufficient to
cause memory corruption'. 
As mentioned by ag0aep6g, an uninitialized array can allow you to pass the
guard page that prevents stack overflow. Therefor, using uninitialized arrays
on the stack is sufficient to cause memory corruption and should be fixed for
@safe code. Can you show that union member access is sufficient for memory
corruption? 

Alternatively, can you give a new, better definition of @safe that includes
union member access and excludes the earlier mentioned risky language
constructs?

> it's the first and most obvious place any sane security engineer
> will look for attack surface.

In C, definitely. He will also look for suspicious for-loops and non-trivial
bounds checks. Here's an example of one:
CUTE_PNG_CHECK(s->out - backwards_distance >= s->begin, "Attempted to write
before out buffer (invalid backwards distance).");
https://github.com/RandyGaul/cute_headers/blob/master/cute_png.h#L499

--