On Wednesday, 18 June 2014 at 06:35:01 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 17 June 2014 at 22:44:00 UTC, Timon Gehr wrote:
As you know this will not single out _exactly_ the subset of
programs which is memory safe which is the claim I was arguing
against,
It will single out exactly the programs that are most certainly
memory safe, and also single out those programs that have
generated unsafe features (instructions). Whether those unsafe
features sit in a basic block that will never called is a
different matter since @safe does not address that.
So yes, @safe is not equivalent to memory safety, it is
equivalent to the absence of FEATURES that can lead to
situations that aren't memory safe. But that is splitting hairs.
That isn't splitting hair. You are loosing track of the big
picture here. To come back to the original problem :
memset(&foo, 0, typeof(foo).sizeof);
Walter mention that this is not corrupting memory and therefore
@safe. In the situation of tail pad optimization, it is obviously
not valid anymore and will cause memory corruption. The
discussion then derailed to what is @safe, as the code is
certainly @safe, but it is difficult to prove it is
automatically) and the fact that @safe is defined backward (ie by
listing what is not allowed and adding to the list when new holes
are discovered rather than listing what is allowed and adding to
the list when some construct are proven to be @safe).
