On Tuesday, 13 December 2022 at 01:35:48 UTC, areYouSureAboutThat wrote:

I mean like this:

import std.stdio;
void main() @safe {
  writeln("Hello, world!");
}

$ dmd -g hello.d
$ gdb ./hello
(gdb) b write
(gdb) r
Breakpoint 1, 0x00007ffff7714bb0 in write () from /lib64/libc.so.6

(gdb) bt
#0  0x00007ffff7714bb0 in write () from /lib64/libc.so.6
#1  0x00007ffff7699ecd in _IO_file_write@@GLIBC_2.2.5 () from /lib64/libc.so.6
#2  0x00007ffff7699256 in new_do_write () from /lib64/libc.so.6
#3  0x00007ffff769af69 in __GI__IO_do_write () from /lib64/libc.so.6
#4  0x00007ffff769b393 in __GI__IO_file_overflow () from /lib64/libc.so.6
#5  0x0000555555557110 in std.stdio.File.LockingTextWriter.put!(char).put(char)
#6  0x00005555555563a0 in std.stdio.writeln!(immutable(char)[]).writeln(immutable(char)[])
#7  0x00005555555562e0 in D main () at ./hello.d:3

(gdb) disassemble
Dump of assembler code for function write:
=> 0x00007ffff7714bb0 <+0>:     mov    %fs:0x18,%eax
   0x00007ffff7714bb8 <+8>:     test   %eax,%eax
   0x00007ffff7714bba <+10>:    jne    0x7ffff7714bd0 <write+32>
   0x00007ffff7714bbc <+12>:    mov    $0x1,%eax
   0x00007ffff7714bc1 <+17>:    syscall
   0x00007ffff7714bc3 <+19>:    cmp    $0xfffffffffffff000,%rax
   0x00007ffff7714bc9 <+25>:    ja     0x7ffff7714c20 <write+112>
   0x00007ffff7714bcb <+27>:    ret

That's how you go from a @safe function main() down to a syscall instruction (then the rest is happening in the Linux kernel). Somewhere on this way a @trusted attribute needs to be used, which means "please @trust me, these particular potentially unsafe things are used correctly here and won't cause troubles": https://github.com/dlang/phobos/blob/v2.101.0/std/stdio.d#L3187

As the end users, we expect that Phobos interacts with a dangerous system library (libc) in a correct way. Phobos itself annotates trustedFPUTC/trustedFPUTWC functions imported from glibc as @trusted and expects that they are interacting with the OS kernel correctly without causing troubles.

It's impossible to do a syscall by using just @safe code and nothing else.

On Tuesday, 13 December 2022 at 01:50:26 UTC, areYouSureAboutThat wrote:

This isn't any different from D.

@system void f() { return; } // This is the unsafe code

@safe void main() {
    // error: `@safe` function `D main` cannot call `@system` function `app.f`
    f();
}

@safe void main() {
    () @trusted { f(); }(); // ok!
}

The difference is that D lets you also write

@trusted void main() {
    f(); // ok!
}

This is really just a nice shorthand for the @safe main with @trusted lambda inside. It's also a better practice, since @trusted in a function signature is easier to spot for a code reviewer than the lambda inside the function.

On Tuesday, 13 December 2022 at 05:26:23 UTC, areYouSureAboutThat wrote:

You can be sure that your @safe code is always calling at least some small amount of @trusted code inside of Phobos.

Yes, it could be all marked as @trusted, but it isn't. Also Phobos or any other third-party library theoretically could do a lot of various bad things with or without @safe annotations. Some libraries have better code quality than the others and that's just how it is.

If these @trusted parts of Phobos are bug free, then everything is fine. Your code shouldn't be able to trigger memory safety bugs in Phobos by feeding incorrect input to it.

As I already said before, you will effectively have to always use this switch for compiling each and every application.

I guess, you probably want the @trusted parts of Phobos to be annotated as @supertrusted and ignored by this switch, because it's the standard library deserving special privileges? And only complain about the @trusted attribute usage in your own code or in third-party libraries written by plebeians ;-)

On Wednesday, 14 December 2022 at 20:54:44 UTC, areYouSureAboutThat wrote:

Dukc already explained it, but let me show some practical examples. Here's a buggy program in Rust:

use std::slice;

unsafe fn f(i: usize) -> i32 {
    let mut arr = [1, 2, 3];
    let s = slice::from_raw_parts_mut(arr.as_mut_ptr(), 1000);
    return s[i];
}

fn main() {
    unsafe { println!("{}", f(3)); } // ok!
}

And here's exactly the same buggy program converted to D:

@safe: import std;

@system int f(size_t i) {
    auto arr = [1, 2, 3];
    return arr.ptr[i];
}

void main() {
    () @trusted { writeln(f(3)); }(); // ok!
}

Both Rust and D compilers accept this code without complaining. Such code can be unknowingly compiled into your library. It may be a part of the standard library, or it may be a part of some third-party library that you want to use. And if the bug is difficult to reproduce, then you even won't be aware of it.

Now if you review the code, then D code is much more readable than Rust. If you want to find the boundary between safe and unsafe code in D, then you can just search for the "@trusted" attribute. But in Rust you can't easily find the boundary between safe and unsafe code, because the same "unsafe" keyword is reused for different purposes.

It's is very different. If you look at a function as a black box without knowing what is inside, then:

• @trusted function is typically safe to use. But this safety is guaranteed by human reviewers, because the compiler is not smart enough to do such analysis. It's important that the way how such functions are handling their input/output data is reasonably foolproof.

• @system function may have some dangerous quirks and can be easily misused to shoot yourself in the foot (leak resources, segfault on incorrect input, deadlock when used from multiple threads, ...). It can be used correctly if the user is very careful, but allowing to call such function directly from the @safe code would be reckless.