So these two compile and, in non-debug builds, run just fine

[Ethan Watson via Digitalmars-d]

MyClass* getAPointer()
{
   MyClass* ptr;
   MyClass instance = new MyClass();
   ptr = &instance;
   return ptr;
}

MyStruct* getAnotherPointer()
{
   MyStruct* ptr;
   MyStruct instance;
   ptr = &instance;
   return ptr;
}

One of the guys here is working on some GC stuff (ARC related), 
and gave me a snippet of code that took a reference to a class on 
the stack, and assigned the address of it to another variable. 
Which meant that when the class reference goes out of scope, it's 
pointing to data on the stack that shouldn't be valid.

And you can break it in debug with a little bit of code as such:

MyClass* ptr = getAPointer();
MyStruct* someStruct = getAnotherPointer();
writeln( to!string( (*ptr).foo ) );

I wouldn't expect this to be something that can be detected at 
compile time. I mean, the code looks simple enough, but it's just 
the easiest way to show off the larger problem that returning by 
pointer is not validated. Ten minutes and you could write some 
horribly obfuscated code that still gives a return value that's a 
stack pointer.

I'm sure this sounds bad. And it is.

Related to this: 
https://msdn.microsoft.com/en-us/library/8dbf701c.aspx

The Windows App Certification Kit can pick up if the security 
token check isn't done on enter and exit of a function. And even 
if the codegen does the checks, stack pointers mean you can start 
doing stack overflows.