On Sunday, 24 May 2020 at 01:26:02 UTC, ag0aep6g wrote:
On 24.05.20 02:55, Arine wrote:
That works even if you make the static this() @safe, and
remove the pointer incrementation.
Sure. `*p = 13;` is perfectly @safe. The static constructor
isn't needed for that part. You can just as well do the
assignment in `main`. The static constructor is another feature
that can smuggle unsafe code (the increment) into your program
without the @trusted warning label.
It'd be no different than passing the pointer into @safe code as
a parameter from @system code. Ultimately the error occurs in
@system code and directly as a result of @system code. It is
undefined behavior as well. No amount of safe code can save you
from that.
You'd have to make the p initialization @safe.
@safe:
int* p = cast(int*) &x; // error
But note this doesn't work:
@safe int* p = cast(int*) &x; // compiles
Having the default become @safe will help detect this, as I
don't imagine that is a whole lot of usage of @safe: to begin
with.
The example compiles with `-preview=safedefault`. And even if
that gets changed, it will probably still compile when marked
@system. So we still won't find it when looking for "@trusted".
Then that is definitely a bug if that's the case. Someone should
probably make a bug report, Walter? If you are still using
@system with @safe, then that would still be somewhere you have
to look for not memory safe code. @trusted should just mean that
someone verified it. @system then would mean no one's verified it
to be safe, that doesn't mean you don't have to check it.
