safety model in D

[Rainer Deyke]

Andrei Alexandrescu wrote:
> Rainer Deyke wrote:
>> You're forgetting about all other system programming languages.

Delphi.

>>  Also,
>> many of these claims to safety are demonstrably false.
> 
> Which?

I can get Python to segfault.

> Memory safety is defined formally in Pierce's book.

Do you mean "Types and programming languages" by Benjamin C. Pierce?
According to Google books, it does not contain the phrase "memory
safety".  It does contain a section of "language safety", which says
that "a safe language is one that protects its own abstractions".  By
that definition, machine language is safe, because it has no
abstractions to protect.

Another quote: "Language safety can be achieved by static checking, but
also by run-time checks that trap nonsensical operations just at the
moment when they are attempted and stop the program or raise an
exception".  In other words, Pierce sees runtime checks and compile-time
checks as orthogonal methods for providing the same safety.

> Undefined behavior
> is defined by the C++ standard.

Undefined behavior is a simple concept: the language specification does
not define what will happen when the program invokes undefined behavior.
 Undefined behavior can be trivially eliminated from the language by
replacing it with defined behavior.  If a language construct is defined
to trash the process memory space, then it is not undefined behavior.

> Cardelli defines trapped and untrapped
> errors.

Untrapped error: An execution error that does not immediately result in
a fault.

I can't find his definition of "execution error", which makes this
definition useless to me.


-- 
Rainer Deyke - rainerd at eldwood.com