dangling-pointer

What set of GCC options provide the best protection against memory corruption vulnerabilities such as Buffer Overflows, and Dangling Pointers? Does GCC provide any type of ROP chain mitigation? Are there performance concerns or other issues that would prevent this GCC option from being on a mission critical application in production? I am looking at the Debian Hardening Guide as well as GCC Mudflap . Here are the following configurations I am considering: -D_FORTIFY_SOURCE=2 -fstack-protector --param ssp-buffer-size=4 -fPIE -pie -Wl,-z,relro,-z,now (ld -z relro and ld -z now) Are there any

Consider a method that returns a std::string_view either from a method that returns a const std::string& or from an empty string. To my surprise, writing the method this way results in a dangling string view: const std::string& otherMethod(); std::string_view myMethod(bool bla) { return bla ? otherMethod() : ""; // Dangling view! } https://godbolt.org/z/1Hu_p2 It seems that the compiler first puts a temporary std::string copy of the result of otherMethod() on the stack and then returns a view of this temporary copy instead of just returning a view of the reference. First I thought about a

I've read How to demonstrate memory leak and zombie objects in Xcode Instruments? but that's for objective-c. The steps don't apply. From reading here I've understood zombies are objects which are: deallocated but something pointer is still trying to point to them and send messages to them. not exactly sure how that's different from accessing a deallocated object. I mean in Swift you can do: var person : Person? = Person(name: "John") person = nil print(person!.name) Is person deallocated? Yes! Are we trying to point to it? Yes! So can someone share the most common mistake which leads to

A question came up here on SO asking "Why is this working" when a pointer became dangling. The answers were that it's UB, which means it may work or not. I learned in a tutorial that: #include <iostream> struct Foo { int member; void function() { std::cout << "hello";} }; int main() { Foo* fooObj = nullptr; fooObj->member = 5; // This will cause a read access violation but... fooObj->function(); // Because this doesn't refer to any memory specific to // the Foo object, and doesn't touch any of its members // It will work. } Would this be the equivalent of: static void function(Foo* fooObj) //

In the following code segment, after free(x) , why does y become 0? As per my understanding, the memory in the heap that was being pointed to by x , and is still being pointed to by y , hasn't been allocated to someone else, so how can it change to 0? And moreover, I don't think it is free(x) that changed it to 0. Any comments? #include <stdio.h> int main(int argc, char *argv[]) { int *y = NULL; int *x = NULL; x = malloc(4); *x = 5; y = x; printf("[%d]\n", *y); //prints 5 free(x); printf("[%d]\n", *y); //why doesn't print 5?, prints 0 instead return 0; } This is undefined behavior,