How does D improve design practices over C++?

Jarrett Billingsley jarrett.billingsley at gmail.com
Wed Oct 29 14:50:20 PDT 2008


On Wed, Oct 29, 2008 at 5:43 PM, Brad Roberts <braddr at puremagic.com> wrote:
> On Wed, 29 Oct 2008, Walter Bright wrote:
>
>> bearophile wrote:
>> > D1 is often safer than C and C++, but regarding safety there are
>> > several things that can improved still, often with no/little
>> > performance penalty (unsafe casting (automatic and manual), integral
>> > overflows, GC pointers Vs other pointers, nonnull types, named
>> > arguments, fallthrough switch cases, multi var assigns syntax
>> > missing, octal literals, bitwise operators as symbols instead English
>> > words, and many other smaller things I have listed in the past). You
>> > may want to tell them about the idea of SafeD too (javesque D).
>>
>> "Safety" in programming languages does not refer to program correctness, but
>> absence of bugs that could result in memory corruption. The agenda of SafeD is
>> to find the subset of D that can guarantee there is no memory corruption.
>>
>> Null pointer dereferencing, for example, is a program bug but is not a safety
>> issue because it cannot cause memory corruption.
>
> Actually, that's not true.  Dereferencing null _can_ corrupt memory.  As
> you well know, ptr[index] is just ptr + index.  Use a large and accurate
> enough index and you're out of that first page of memory and back into
> application memory space.  Find the address of a key stack variable and
> you've got room for all sorts of fun and mahem.
>
> These are the sorts of bugs in popular enough applications are the things
> that end up costing companies lots of money to emergency fix.  One of the
> few recent flash exploits were exactly this type of bug.
>
> Later,
> Brad
>

Interestingly, although null dereferences are unsafe, in a safe
language like SafeD it's not actually possible to do so.  There are no
pointers and arrays are bounds-checked.  So with the combination of
the typing system and the runtime checks, null can never actually be
dereferenced, so no special consideration has to be given to it.



More information about the Digitalmars-d mailing list