Memory Corruption in Delphi
blog.includesecurity.com
blog.includesecurity.com
So why not simply eliminate these unsafe features? The answer is --- speed.
What makes C/C++ suspect with regard to safety is the fact that these languages tend to promote unsafe features and constructs as standard practice and offer no realistic alternative using their standard libraries.
It's possible to build/invent anything using these languages including safe practices --- but the end result will wind up looking foreign to most who normally use these languages and cost more than their employers normally expect to pay.
The FreePascal compiler would warn about the missing init (first example of the "The Heap and Use After Free" section).
That being said I think that uninitialized locals is really something from an other age. Modern languages should always default-initialize locals. Speed of execution is not an issue as optimizing-compilers are able to remove dead assignments.
Inline variable declaration with initialization makes it a bit nicer. You can write:
var myVar := 25;
To initialize myVar and type inference will make it an Integer. You can specify type if needed: var myVar : Integer := 25;
In their examples they say: ShowMessage('obj2.n2: ' + IntToStr(obj2.n2)); // Shows 0 - uninitialized memory
But actually n2 is initialized to zero.And in the example freeing of objects, instead of using:
obj1.Free;
They should always use: FreeAndNil(obj1);
That will free the object and set the object pointer to nil. Any subsequent attempt to access obj1 will result in an access violation.