@system blocks and safer @trusted (ST) functions
claptrap
clap at trap.com
Thu Jul 29 13:20:41 UTC 2021
On Thursday, 29 July 2021 at 08:16:08 UTC, Joseph Rushton
Wakeling wrote:
> On Wednesday, 28 July 2021 at 17:25:18 UTC, claptrap wrote:
>> Do you have ideas on how to stop unsafe blocks accessing the
>> variables from the surrounding scope? Is that even a goal for
>> the DIP?
>
> I'm not sure it necessarily is. Consider the following example
> (using the proposed @trusted-with- at system-blocks syntax):
>
>
> ```D
> /// Writes something into the provided buffer, e.g. filling the
> /// buffer with random bytes
> extern(C) void writeIntoCBuffer (int* ptr, size_t len) @system;
>
>
> void writeIntoDBuffer (ref int[] buf) @trusted
> {
> @system { writeIntoCBuffer(buf.ptr, buf.length); }
> }
> ```
>
> That seems like a reasonable use-case for a @trusted wrapper of
> an underlying @system function, but if the @system block was
> forbidden from accessing variables from the surrounding scope,
> it wouldn't be possible.
>
> Does that make sense, or have I misunderstood what you had in
> mind?
Not exactly, obviously if they cant access variables from the
surround scope they'd be useless. But i think the idea (not
something i knew about until this thread) is to have a safe api
between trusted and system. So there's controlled / restricted
access. Otherwise if you have a system block inside a trusted
function, the system code could just trash anything it wants from
the enclosing scope, which makes any guarantees you have from the
code being checked a bit pointless.
So it's not just about narrowing down the amount of code that is
marked @system, but also the amount of state that it can access.
IIUC that was the original reason for limiting
@safe/@trusted/@system to only apply on functions. So it forces
you think about API between them. But I guess it didn't work out
as expected.
More information about the Digitalmars-d
mailing list