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.
