Tail pad optimization, cache friendlyness and C++ interrop
via Digitalmars-d
digitalmars-d at puremagic.com
Tue Jun 17 14:50:04 PDT 2014
On Monday, 16 June 2014 at 13:12:33 UTC, Timon Gehr wrote:
> My point was that no implementation of @safe whatsoever can
> make it _equivalent_ to memory safety (i.e. @safe will never
> single out precisely those programs that do not corrupt
> memory). It will always only approximate memory safety. This is
> not a bug, it's just a fact.
Out of curiosity, what is "memory safety" defined to be? Does it
include running out of stack?
It should not be a problem if @safe rejects some memory safe
programs. It still verifies that they are memory safe if they
pass (as opposed to "if and only if"). You can verify subsets
even if you cannot define two crisp set that discriminate between
all possible programs.
Btw, Rice's theorem is based on the halting problem for TMs… so
it suffers from the same issues as everything else in theoretical
CS when it comes to practical situations. Whether generated IR
contains unsafe instructions is trivially decidable. Since you
can define an IR in a way that discriminate between unsafe/safe
instructions you can also decide that the safe subset is
verifiable memory safe.
> to agree on. In this case this is witnessed by the fact that
> you do not seem to want to ban undefined behaviour from @safe
> code which I can't agree with.
Then just define the undefined behaviour as yielding the integer
result of a unspecified black box function of the input. Integer
overflow should yield the same value for the same operands on all
ALUs. I don't understand how this relates to memory safety?
More information about the Digitalmars-d
mailing list