Can we just have struct inheritence already?

Timon Gehr timon.gehr at gmx.ch
Thu Jun 13 00:18:42 UTC 2019


On 11.06.19 13:03, Walter Bright wrote:
> 
> Here is what memory safety means:
> 
> "Memory safety is the state of being protected from various software 
> bugs and security vulnerabilities when dealing with memory access, such 
> as buffer overflows and dangling pointers."
> 
>    -- https://en.wikipedia.org/wiki/Memory_safety
> 
> D defines @safe as "memory safe". It does not define it as "no undefined 
> behavior".
> ...

Memory safety very much implies there can't be undefined behavior. 
Undefined behavior means the program can do anything, including 
overflowing buffers or freeing memory without destroying all references 
pointing to it. You may want to define it differently, but there is 
really no point. It will just confuse everyone who is familiar with 
another programming language that uses the standard meaning of the term.

> D does fall short of that goal, because it doesn't thoroughly track 
> allocated memory pointers. But that has nothing to do with undefined 
> values for integers.

Undefined values are not undefined behavior.


However, there are potential problems, based on which properties you 
want to assume that strongly pure functions have:

int foo()@safe pure{
     int x=void;
     return x;
}

Any code that is optimized based on the assumption that `foo()` will 
always return the same value will have undefined behavior, including the 
possibility of buffer overflows or dangling pointers.


More information about the Digitalmars-d mailing list