Max Samukha wrote:
Lionello Lunesu wrote:
On 27-9-2009 9:20, Walter Bright wrote:
language_fan wrote:
The idea behind non-nullable types and other contracts is to catch
these errors on compile time. Sure, the code is a bit harder to write,
but it is safe and never segfaults. The idea is to minimize the amount
of runtime errors of all sorts. That's also how other features of
statically typed languages work.
I certainly agree that catching errors at compile time is preferable by
far. Where I disagree is the notion that non-nullable types achieve
this. I've argued extensively here that they hide errors, not fix them.
Also, by "safe" I presume you mean "memory safe" which means free of
memory corruption. Null pointer exceptions are memory safe. A null
pointer could be caused by memory corruption, but it cannot *cause*
memory corruption.
// t.d
void main()
{
int* a;
a[20000] = 2;
}
[C:\Users\Lionello] dmd -run t.d
[C:\Users\Lionello]
This code passes on Vista. Granted, needs a big enough offset and some
luck, but indexing null will never be secure in the current flat memory
models.
L.
That is a strong argument. If an object is big enough, modifying it via a
null reference may still cause memory corruption. Initializing references to
null does not guarantee memory safety.
How is that corruption? These pointers were purposely set to 0x00000002,
corruption I believe is when memory is modified without the programmer
being aware of it. For example if the GC was to free memory that is
still reachable, that would cause corruption.
Corruption is near impossible to trace back, this case is trivial.
