@trusted assumptions about @safe code
Paul Backus
snarwin at gmail.com
Wed May 27 00:50:26 UTC 2020
On Tuesday, 26 May 2020 at 22:52:09 UTC, ag0aep6g wrote:
> But yeah, the @trusted function might rely on the @safe
> function returning 42. And when it suddenly returns 43, all
> hell breaks loose. There doesn't need to be any monkey business
> with unsafe aliasing or such. Just an @safe function returning
> an unexpected value.
>
> I suppose the only ways to catch that kind of thing would be to
> forbid calling @safe (and other @trusted?) functions from
> @trusted (and @system?) code, or to mandate that the exact
> behavior of @safe functions (including their return values)
> cannot be relied upon for safety. Those would be really, really
> tough sells.
All that's necessary is to have the @trusted function check that
the assumption it's relying on is actually true:
@safe int foo() { ... }
@trusted void bar() {
int fooResult = foo();
assert(fooResult == 42);
// proceed accordingly
}
If the assumption is violated, the program will crash at runtime
rather than potentially corrupt memory.
More information about the Digitalmars-d
mailing list