D - Unsafe and doomed

[H. S. Teoh]

On Sat, Jan 04, 2014 at 12:10:20AM -0800, Walter Bright wrote:
> On 1/3/2014 11:42 PM, ilya-stromberg wrote:
> >NULL pointer means that I don't have any valid object, and it's good
> >situation.  But there are a lot of situations when function must take
> >a valid object (at least NOT NULL pointer). D allows:
> >
> >1) use `if(p is null)` and than throw exception - it will be safe,
> >but I have additional `if` check
> >2) ues `assert(p !is null)` - theoretically, it will be safe, but
> >program can have different situation is realise mode and fails (for
> >example, because nobody provide the same example in debug mode)
> >3) do nothing - programmer just forgot to add any checks
> >
> >Also, I must to add unit tests for every posible case usage of that
> >function with a valid object. So, it's kind of dynamic typing that
> >can be done by compiler type system.
> >
> >So, in a few cases null pointers are a safety issue.
> 
> I believe this is a misunderstanding of what safety is. It means
> memory safety - i.e. no memory corruption. It does not mean "no
> bugs".
> 
> Memory corruption happens when you've got a pointer to garbage, and
> then you read/write that garbage.
> 
> Null pointers seg fault when they are dereferenced, halting your
> program. While a programming bug, it is not a safety issue.

Keep in mind, though, that for sufficiently large objects, null pointers
may not segfault (e.g., when you dereference a field at the end of the
object, which, when large enough, will have a sufficiently large address
to not cause a segfault when the base pointer is null -- you *will* end
up with memory corruption in that case).


T

-- 
In theory, software is implemented according to the design that has been
carefully worked out beforehand. In practice, design documents are
written after the fact to describe the sorry mess that has gone on
before.